Model 990 Computer 

■ 

U^^ y vjpgiQ'iiiiQ wyStSfTl KGIG3SG 3-4 

System Design Document 





Part No. 939153-9701 *C 
1 October 1981 



Texas Instruments 



LIST OF EFFECTIVE PAGES 



INSERT LATEST CHANGED PAGES AND DISCARD SUPERSEDED PAGES 

Note: The changes in the text are indicated by a change number at the bottom of the page and a vertical bar in the other 
margin of the changed page. A change number at the bottom of the page but no change bar indicates either a deletion or a 
page layout change. 

Model 990 Computer DX10 Operating System Release 3.4 System Design Document (939153-9701) 

Original Issue 15 December 1977 

Revision 15 December 1979 

Revision 15 April 1981 

Change 1 1 October 1981 



Total number of pages in this publication is 302 consisting of the following: 



PAGE 
NO. 

Cover 

Effective Pages 
iii -v 



CHANGE 
NO. 



...1 
...1 

...0 

vi 1 

vii- viii 

ix-x 1 

xi-xii 

1-1-1-40 

2-1-2-4 

3-1-3-6. 

4-1-4-7 

4-8 1 

4-9-4-27 

4-28-4-31 1 

4-32 - 4-46 

5-1-5-4 



PAGE 
NO. 



CHANGE 
NO. 



6-1-6-8 

6-9-6-11 1 

6-12-6-17 

6-18 1 

6-18A-6-18F 1 

6-19-6-50 

6-51 - 6-55 1 

6-56-6-60 

6-61 1 

6-62-6-66 

6-67 1 

6-68 

7-1-7-2 

8-1-8-4 1 

9-1-9-12 

9-13-9-14 1 



PAGE 
NO. 



CHANGE 
NO. 



9-15-9-18 

9-19 1 

9-20-9-28 

10-1-10-22 

10-23/10-24 1 

A-1-A-18 

B-1-B-6 

C-1-C-12 

D-1/D-2 

E-1-E-2 

F-1-F-14 

User's Response 

Business Reply 

Sales and Service — 
Cover 



© Texas Instruments Incorporated 1977, 1979, 1981 
All Rights Reserved 

The information and/or drawings set forth in this document and all rights in and to inventions 
disclosed herein and patents which might be granted thereon disclosing or employing t^e 
materials, methods, techniques or apparatus described herein are the exclusive properly of 
Texas Instruments Incorporated. 



System Design Document Preface 



PREFACE 

The purpose of this manual is to familiarize the reader with the flow 
of control between major parts of the DX10 operating system, with the 
internal data structures used, and with the organization of the system 
disk. 

The manual is organized into the following sections: 

1. DX10 Implementation Tutorial — Describes the general 
concepts used throughout DX10 and control paths through ma.ior 
parts of DX10. 

2. Organization and Structure of DX1 Source Libraries — 
Describes the organization of the DX1 source disk, and 
includes a disk map. 

?. System Loaders — Describes the software necessary to start 
up a DX10 system, including the boot loader, disk loader, 
DX10 loader, and system restart task. 

4. Disk Organization • — Describes the physical and logical 
format of a DX10 disk, as well as the internal structure of 
all file types that are supported. 

5- System Piles — Describes some special files used by DX10. 

6. Data Structures — Describes many of the internal data 
structures built and maintained by DX10. 

7. DX10 Data Base Modules — Describes the information contained 
in the two data modules within DX10. 

8. Common System Routines — Names and describes the stacking 
and queueing routines used by many of the system routines. 

9- DX10 Source Modules — Contains a tabularized description of 
the most important modules in DX10. 

10. System Command Interpreter — Describes the separate 
functional parts of the system command interpreter (SCI) and 
the flow of control between those parts. 

This manual also includes appendices that describe how to analyze 
system crashes; how to regenerate DX10, SCI, SDSMAC, and the link 
editor from the source; the scheduler structure and operation; the 
effect of device states on LUNO assignment; VDT character input; and 
operation of the system level debugger. 
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This manual assumes that the user has a detailed, working knowledge of 
the information contained in the following Model 9^0 Computer Manuals: 

DX10 Operating System Concepts and 

Facilities Manual 946250-9^01 

DX10 Operating System Production 

Operation Manual 946250-9702 

DX10 Operating System Application 

Programming Guide 046250-9^0^ 

DX10 Operating System Developmental 

Operation Manual 946250-9704 

DX10 Operating System 

Systems Programming Guide 946250-^05 

DX10 Operating System Error Reporting 

and Recovery Manual 346250-^06 



Texas Instruments iv a^ai ^_q-7Qi 



System Design Document 



Table of Contents 



Paragraph 



TABLE OP CONTENTS 
Title 



Page 



1 


.1 


.1 




1 


.1 


.2 




1 


.1 


.3 




1 


.1 


.4 




1 


.2 






1 


.2 


.1 




1 


.2 


.2 




1 


.2 


.3 




1 


.2 


• 3- 


1 


1 


,2 


.3. 


2 


1 


.2 


-3. 


3 


1 


.2 


4 




1 


.2 


5 




1 


.2. 


5. 


1 


1 


.2, 


5- 


2 


1 


.2. 


6 




1 


.2. 


6. 


1 


1 


.2. 


6. 


2 


1 


.2. 


7 




1 


.2. 


7. 


1 


1 


.2. 


7. 


2 


1 


.2. 


7. 


3 


1 


.2. 


7. 


4 


SECTION 


2 


1 






2. 


2 







SECTION 1 DX10 IMPLEMENTATION TUTORIAL 

General Concepts 

Queue Servers 

A 32-Byte Block of Memory — Beets. . . 

Calling Conventions 

System Memory Mapping 

How Parts of DX10 Pit Together 

SVC Processing 

Bidding a Task . 

Scheduling, Loading, and Rolling a Task 

Scheduling 

Loading And Rolling , 

Memory Management , 

Device I/O Plow , 

Pile Utility Plow . . , 

Assigning and Releasing LUNOs . . . , 

Creating and Deleting Piles 

Pile I/O Plow 

Blocked Pile I/O 

Unblocked Pile I/O 

Task Termination 

End Task/End Program SVC 

Suspend Awaiting Queue Input SVC. . . 

Error Termination 

Kill Task SVC 



2 ORGANIZATION AND STRUCTURE OP DX1 SOURCE LIBRARIES 



1-3 

1-S 

1-6 

1-6 

-11 

-11 

-1^ 

-18 

-18 

-18 

-22 

-26 

-28 

-31 

-M 

-34 

-3^ 

_37 

-38 
-38 
-39 
-39 



General 

Top Level Directories 



2-1 
2-1 



3-1 
"5.2 
3-3 
3-4 
3-5 



SECTION 3 SYSTEM LOADERS 

General 3_1 

The Boot Loader 3-2 

The Disk Program Image Loader 3-3 

The System Loader/initializer 3-3 

The System Restart Task 3-4 



939153-9701 



v 



Texas Instruments 



Table of Contents System Design Document 

TABLE OF CONTENTS (Continued) 

Paragraph Title Page 
SECTION 4 DISK ORGANIZATION 

4.1 Disk Format 4-1 

4.2 Physical Organization of the Disk 4-1 

4.2.1 Volume Information 4-2 

4.2.2 Allocation Bit Map 4-6 

4.3 File Structures 4-7 

4.3.1 Relative Record Files 4-8 

4.3.1.1 Unblocked Relative Record Files 4-8 

4.3.1.2 Blocked Relative Record File 4-9 

4.3.2 Sequential Files 4-9 

4.3.3 Key Indexed Files 4-13 

4.3.3.1 B-Trees 4-13 

4.3.3.2 Data Blocks . .• 4-17 

4.3.4 Special Relative Record Files 4-19 

4.3.4.1 Program Files 4-19 

4.3.4.2 Directory Files 4-29 

4.3.4.3 Image Files 4-42 

SECTION 5 SYSTEM FILES 

5.1 General 5-1 

5.2 System Program File 5-1 

5.3 System Overlay File 5-3 

5.4 Crash File q -4 

5.5 Roll File 5-4 

SECTION 6 DATA STRUCTURES 

6.1 General 6-1 

6.2 Queues 6-1 

6.3 Physical Device Table ....... 6-2 

6.3.1 PDT Expansion Block 6-7 

6.3.2 Disk PDT Extension (DPD) 6-8 

6.3.3 Teleprinter Device PDT Extension (DIB) 6-11 

6.3.4 Keyboard Status Block (KSB) 6-14 

6.3.4.1 Video Display Terminal Extension (VDT) . . . . 6-17 
6.3.4.1A Electronic Video Terminal Extension (VDT940) 6-18 

6.3.4.2 KSR Extension (KSR) 6-18F 

6.3.4.3 820 Extension (T82) 6-20 

6.3.4.4 Character Queue 6-21 

6.3.5 Line Printer Extension (LPD) 6-21 

6.3.6 Tape Extension (TPD) 6-23 

6.3.7 Floppy Diskette Extension (FPD) 6-24 

6.4 File Control Block (FCB) 6-25 

6.4.1 KIF Extension to the FCB 6-30 

6.4.2 Queue Extension to the FCB 6-32 

6.4.3 Record Lock Table (RLT) 6-33 

6.4.4 Program File Extension to the FCB 6-34 

6.5 Logical Device Table (LDT) 6-35 

6.6 Buffered Call Block 6-37 

6.7 Task Status Block (TSB) 6-38 

Texas Instruments vi (Change 1) 939153-9701 



System Design Document 



Table of Contents 



TABLE dtp nrvNrfpwns ( r^ + i^^a\ 



Paragraph 

6.8 

6.9 

6.10 

6.10.1 

6.10.2 

6.10.5 

6.10.4 

6.10.5 

6.10.6 

6.10.7 

6.10.8 

6.11 

6.12 

6.13 

6.13.1 
6.13.2 



Title 



Page 



Procedure Status Block (PSB) 6-45 

Time Ordered List (TOL) 6-47 

System Log Parameter Blocks (SLPB) 6-49 

Device Extension with Controller Image (SLXKEY-0) 6-51 

User Call Extension to SLPB (SLXKEY - 1) ... . 6-52 

Memory Error Extension to SLPB (SLXKEY -2). . . 6-52 

Statistics Extension to SLPB (SLXKEY = 3). . . . 6-53 

Interrupt Extension to SLPB (SLXKEY - 4) ... . 6-53 

Task Extension to SLPB (SLXKEY =6^ 6-54 

Cache Memory Extension to SLPB (SLXKEY =8). . . 6-54 

SLPB Device Extension with PRB (SLXKEY = q). . . 6-55 

System Overlay Table (OVT) 6-55 

Memory Management Lists 6-50 

Structure of the Sequential Eile Created by Backup 

Directory 6-S9 

Backup Directory with NOMULTI Option Selected. . 6-61 

Backup Directory With MULTI Option Specified . . 6-67 



7.1 

7.2 

y .3 



SECTION 7 DX10 DATA BASE MODULES 



G-eneral 
D$DATA. 
DXDAT2. 



7-1 
7-1 
7-2 



SECTION 8 COMMON SYSTEM ROUTINES 



8.1 STACKING ROUTINES 

8.2 QUEUING ROUTINES 

8.2.1 TMQUE 

8.2.2 TMAQUE 

8.2.3 TMAQO 

8.2.4 TMTSBQ 

8.2.5 TMDQUE 

8.2.6 TMSQRM 



8-1 
8-3 
8-1 
8-3 
8-4 
8-4 
8-4 
8-4 



SECTION 9 DESCRIPTION OP DX1 ROUTINES 

9.1 General q_i 

9.2 SVC Processing q_i 

9-3 Bid Task Supervisor Call - Code >05 Q-4 

9« 4 Task Manager q_5 

9*5 Memory Manager 9-10 

9*6 Disk Manager Q-1 4 

9.7 Device I/O Processing 9-17 

9.8 File Utility Routines q_1 q 

• 9 Eile Manager Q-25 

9-9.1 Key Indexed Piles 9-27 



939153-9701 



Vll 



Texas Instruments 



Table of Contents System Design Document 

TABLE OP CONTENTS (Continued) 
Paragraph Title Pa S 

SECTION 10 SYSTEM COMMAND INTERPRETER 



10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 



1 General 1 °~ 1 

2 System Command Interpreter 10-1 

2.1 ' Structure of SCI 1 °~ 1 

2.2 Overlay Strategy \ 0-3 

2.3 Data Structures 1 °-4 

2.3.1 System Communication Area (SCA) 10-4 

2.3.2 SCA Entry 1 0-4 

2.3.3 Text String • • ] 0-5 

2.3.4 Terminal Communications Area (TCA) 10-6 

2.3.5 Terminal Status Block (TSB) 10-^ 

2.3.6 Name Correspondence Table (NCT) 1 0- 7 

2.4 Interfaces 1 " 8 

2.4.1 Calling Sequence 1 °-8 

2.4.2 Terminal Local Pile 10-9 

2.4.3 System Procedure Library 10-9 

2.4.4 Menu Piles 1 °-^ 

2.4.5 TCA Library Pile — .SSTCALIB 10-10 

2.4.6 Poreground TCA Pile — . SSPGTCA 10-10 

2.4.7 Background TCA Pile — .SSBGTCA 10-10 

2.5 SVC Overhead Analysis 10-11 

2.5.1 .BID SVC Overhead for Poreground SCIQQO • • • 10-11 

2.5.2 .BID SVC Overhead In The Task Being Bid . . . 10-11 

2.5.3 .OVLY SVC Overhead for SCI990 1 0-1 2jf 

2.5.4 .OVLY SVC Overhead in the Overlay 1 0-1 2% 

2.5-5 Analysis 10-12 

3 Background Resource Manager 10-13 

3.1 Structure of BRM 10-13 

3.2 Calling Sequence • 10-13 

3.3 Background Communications Area (BCA) 10-14 

4 Queued Task Bid Handler (QBID) 10-14 

4.1 Structure of QBID 10-14 

4.2 Data Structures 10-16 

4.2.1 System Communication Area (SCA) 10-16 

4.2.2 Background Communication Area (BCA) 10-16 

4.2.3 Task Queue Entry 10-16 

4.3 Calling Sequence 10-17 

4.4 Piles 10-17 

4.5 Error Codes 10-17 

5 Queued Output Handler (OQUEUE) 10-18 

5.1 Structure 10-18 

5.2 Data Structures 10-21 

5.2.1 System Communication Area (SCA) 10-21 

5.2.2 Background Communication Area (BCA) 10-21 

5.2.3 Output Queue Entry 10-21 

5.2.4 Pile Environment Table 10-22 

5.3 Calling Sequence 10-22 

5.4 Piles 10-23 

5.4.1 TCA Pile 10-23 

5.4.2 Listing Pile. . . 1 0-23 

5.5 Error Codes 1 0-23| 



Texas Instruments viii 93Q1 53_q701 



System Design Document 

TABLE OF CONTENTS (Continued) 



Table of Contents 



■*' APPENDIXES 

Appendix Title 

A System Crash Analysis 

B Regenerating DX10, SCI, SDSMAC, & XLE From Source 

C Scheduler Structure and Operation 

D Device States and LUNO Assignment 

E VDT Character Input SVCs 

F The System Level Debugger 



Page | 



A-l 
B-l 
C-l 
D-l 

F-l 



939153-9701 (Change 1) 



IX 



Texas Instruments 



Table of Contents System Design Document 

LIST OF FIGURES 

J* 

Figure Title Pa#. 

1-1 DX10 Physical Organization 1-2 

1-2 DX10 Queue Structure 1-4 

1-3 Active Task Queue 

1-4 System Memory Mapping 

1-5 System Map File Schemes 1-8 

1-6 System Map File 1 Schemes 1-9 

1-7 SVC Processing Flow of Control 1-11 

1-8 Bidding a Task 1-12 

1-9 TSB Family Tree 1-14 

1-10 TSB/PSB Relationship 1-15 

1-11 Simplified Flow of Scheduler 1-19 

1-12 Simplified Flow of Loader 1-20 

1-13 Time-Ordered List 1-22 

1-14 Find Memory Flow. 1-24 

1-15 Logical Device Table Hierarchy 1-26 

1-16 Device I/O Processing Flow. 1-28 

1-17 File Utility Calling Processing 1-29 

1-18 Logical Device Table Pointers 1-31 

1-19 FCB and LDT Tree 1-32 

1-20 File I/O Flow 1-35 

4-1 Volume Information Format (VIF) 4-2 

4-2 Partial Bit Map 4-7 

4-3 Sequential File Format 4-11 

4-4 Blank-Suppressed Record 4-12 

4-5 Key Indexed File B-Tree 4-14 1 

4-6 B-Tree Block 4-15™ 

4-7 Data Block 4-18 

4-8 Program File Format 4-21 

4-9 Program File Record Zero 4-22 

4-10 Program File Available Space List 4-24 

4-11 Task Directory Block 4-25 

4-12 Procedure Directory Entry 4-26 

4-13 Overlay Directory Entry 4-28 

4-14 Directory File Structure 4-30 

4-15 Computing Hash Key 4-31 

4-16 Directory Overhead Record Format 4-33 

4-17 File Descriptor Record 4-34 

4-18 Alias Descriptor Record 4-39 

4-19 Key Descriptor Record 4-41 

4-20 Directory File Dump 4-43 

6-1 Queue Anchor 6-1 

6-2 Physical Device Table 6-3 

6-3 Physical Device Table Expansion Block 6-7 

6-4 Disk PDT Extension 6-8 

6-5 Keyboard Status Block 6-11 

6-6 Teleprinter Device Extension to PDT 6-15 

6-7 Video Display Terminal Extension to KSB 6-17 

6-7A Electronic Video Terminal Extension to KSB . . . 6-18A 

6-8 KSR Extension to KSB 6-19 

6-9 820 Extension To KSB 6-20 

6-10 Line Printer Extension 6-22 

6-11 Tape Extension 6-231 

6-12 Floppy Diskette PDT Extension 6-24 ~ [ 

Texas Instruments x (Change 1) 939153-9701 



System Design Document Table of Contents 

LIST OF FIGURES (continued) 

Figure Title Page 

6-14 FCB Extension for Key Indexed Files 6-31 

6-15 Record Lock Table (RLT) 6-^3 

6-16 FCB Extension for Program Files 6-^4 

6-17 Logical Device Table (LDT^I 6-^5 

6-18 Task Status Block (TSB) 6-38 

6-19 Procedure Status Block (PSB) 6-46 

6-20 TOL Overhead Beet 6-48 

6-21 System Log Parameter Block 6-50 

6-22 SLPB Device Extension With Controller 6-51 

6-23 user Call Extension to SLPB 6-52 

6-24 Memory Error Extension to SLPB 6-52 

6-25 Statistics Extension to the SLPB 6-53 

6-26 Interrupt Extension to the SLPB 6-53 

6-27 Task Extension to the SLPB 6-54 

6-28 Cache Memory Extension to the SLPB 6-54 

6-29 SLPB Device Extension with PRB 6-55 

6-30 Directory To Be Backed Up 6-60 

6-31 Control File 6-61 

6-32 Expanded Structure for a Program File 6-61 

6-33 Structure of .SEQFILE 6-62 

6-34 Back-up Directory Tape Format . 6-68 

10-1 SCI Flow of Control 10-2 

10-2 TCA Layout 10-6 

10-3 Terminal Status Block 10-7 

10-4 Name Correspondence Table 10-8 



039153-9^01 xi Texas Instruments 



Table of Contents System Design Document 

LIST OF TABLES 

Table Title Page 

2-1 Top Level Directories 2_2 

4-1 Format Information for Supported Disks 4-1 

5-1 System Overlay Numbers 5-?- 

6-1 Task State Codes 6 ~41 

9-1 SVC Overhead Routines q -2 

9-2 SVC Processors q -^ 

9-3 Task Management Routines 9-6 

9-4 Memory Management Routines 9-10 

9-5 Buffer Management Routines Q-1 2 

9-6 Disk Management Routines 9-1 5 

9-7 Device I/O Processing Routines Q-1 7 

9-8 Device Service Routines 9-1 9 

9-9 File Utility Routines Q -?° 

9-10 File I/O Processors Q -2 C 5 

9-11 Key Indexed File I/O Processors 9-2 17 

10-1 .BID SVC Overhead for SCI 10-11 

10-2 Overhead in the Bid Task 1 0-1 2 

10-"5 .OVLY SVC Overhead for SCI 10-12 

10-4 QBID Subroutine Call m able 10-15 

10-5 OQUEUE Subroutine Call Table 10-20 



Texas Instruments xii q?Q1 S^-Q7Q1 



System Design Document 



DX10 Implementation Tutorial 



SECTION 1 
DX10 IMPLEMENTATION TUTORIAL 



1 . 1 GENERAL CONCEPTS 

The DXIO operating system is physically divided into two parts: 
one is memory resident and the other is disk resident. Memory resident 
DX10 includes: 

.System tables and device buffers 

.System overlay areas 

.Task scheduler 

.Task loader 

•Overlay loader 

.System overlay loader 

.XOP processors 

•Most SVC processors 

.Interrupt processors 

.Some system tasks that may have overlays (e.g., 
disk manager, file manager) 

These parts are linked together when the operating system is generated, 
and loaded into memory when the system is booted, "'forming the nucleus 
of DX10. 

Disk resident parts of DX10 include system overlays and system tasks. 
System overlays are loaded into the system overlay areas reserved 
within the memory resident nucleus. System tasks are loaded into 
available memory and are mapped in (i.e., share memory) with the 
nucleus. 

Figure 1-1 shows a simplified view of DX10 physical organization. 
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Figure 1-1 DX1 Physical Organization 
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The following paragraphs describe several specific concepts utilized in 
DX10. 

1.1.1 QUEUE SERVERS AND ACTIVE TASK QUEUES. 

An important concept in DX1 is that of information queues and 
queue servers. A queue is a first-in, first-out list of data to be 
processed. In DX10, each queue consists of a queue anchor, located in 
the memory-resident nucleus, and the queued blocks of data. Each block 
is linked to the next block in the queue (see Figure 1-2). A queue 
server is a task that is dedicated to the processing of the data blocks 
in its associated queue. For example, the Bid Task SVC processor is a 
disk-resident task that is a queue server. The queue entries are 
buffered supervisor call blocks. 

A queue server operates in the following manner: when an entry is 
placed in the queue, the queue server is activated (bid). The queue 
server, operating as a task under DX10, dequeues an entry from its 
queue and processes it. The queue server continues to dequeue and 
process queue entries until the queue is empty, at which time it 
suspends itself by issuing a Suspend Awaiting Queue Input SVC (code 
>24) • When a new entry is placed in the queue, the queue server is 
activated. 

Nearly all of the functions of DX10 are performed by queue serving 
routines. Many SVC processors (e.g., I/O SVCs, Install Task, Kill 
Task) plus all of the disk-resident SVC processors are queue servers. 

NOTE 

Disk-resident queue servers are pseudo-memory 
resident. When such a task terminates awaiting 
queue input, its memory is not released until it is 
required to load other tasks. At that time, the 
memory is released and the task must be reloaded 
the next time it is bid. 



The active task queue keeps track of the active tasks wihin the 
system. It is organized in priority order (i.e., all tasks of the same 
priority level are grouped together in a list), starting with the 
highest priority level at the top of the queue. The top task on each 
priority list is the oldest task on that list, and the bottom task is 
correspondingly the youngest. The scheduler always causes the top task 
on the active queue to be in execution. The sequence of task execution 
is dependent on the placement of tasks on the appropriate list within 
the queue. Figure 1-3 shows how the active task queue can appear. A 
list is maintained on the queue for each priority level. Figure 1-3 
shows a queue in which priority levels R1 through R38 are void, level 
R39 has two tasks, R40 has one task, and level R41 has three tasks. 
The remaining real time priorities are void with level 1 having five 
tasks, level 2 having three tasks, and level 3 having 5 tasks. 
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Figure 1-2 DX10 Queue Structure 
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Highest priority task 



Lowest priority task 



R1 through R38 lists are void 

T1/R39 I R3Q list 

T2/R39 i 

T3/R40 R40 list 

T4/R41 1 

T5/R41 I R41 list 

T6/R41 i 

< R42 through R1 27 lists void 

T7/1 | 

T8/1 } 

T9/1 ! 1 list 

T10/1 I 

T11/1 | 

T12/2 I 

T13/2 ! 2 list 

T14/2 j 

T15/3 } 

T16/3 } 
T17/3 3 list 

T18/3 I 

T19/3 I 



T1 ,T2 

T3 

T4,T5,T6 

T7,T8,T9,T10,T11 

T12,T13,T14 



- priority R39 

- priority R40 

- priority R41 

- priority 1 

- priority 2 



T15,T1 6^T17,T18,T1 9 - priority 3 

Figure 1-3 Active Task Queue 



1.1.2 A 32-BYTE BLOCK OF MEMORY — BEETS. 

Under DX10 memory management, a beet is defined to "be a 32-byte 
block of memory. A beet address (boundary) is an absolute address that 
can be evenly divided by 32. The concept of a beet address is 
necessary to DX10 memory management in order to fit a 20-bit absolute 
(unmapped) memory address into a 16-bit word. All memory allocations 
are integral numbers of beets, and begin on a beet boundary. 
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1.1.3 CALLING CONVENTIONS. 

Within DX10, routines normally call each other using the following 
sequence: 

BL @SUBR 
DATA ERROR 
NORMAL EQU $ 

where SUBR is the entry label of the routine being called, ERROR is an 
address within the calling routine to which the called subroutine 
should return in case of an error, and NORMAL (i.e., the next 
instruction) is the normal (non-error condition) return point. 

Since the call is made using a BL instruction, R1 1 points to the word 
containing the error return address. The following sequence is 
generally used by the called subroutine, when returning. 



MOV 

JEQ 
ERRET MOV 

RT 
RTNORM INCT 

RT 



@ERRC0D,R0 
RTNORM 
*R11 ,R1 1 

R11 



Put any error code in RO. 
If no error, do normal return 
If error, return to address 
contained in word following 
the call. Normal return 
is to the second word 
after the call. 



Since the return sequence is often used in DX10, a special routine, 
POPO, is provided to perform the return (see the section on common 
routines) . 



1.1.4 SYSTEM MEMORY MAPPING. 

Using the memory mapping opt 
the DX10 operating system is divid 
schemes using map files and 
include the DX10 data base, syst 
routines (called the system root) 
allows a program to be divided int 
contiguous memory locations) . All 
the I/O common routines (routi 
routines) as the second segment, 
schemes is one of the following: 



ion available on the 990/10 computer, 
ed into several different mapping 

1 (Figure 1-4). All mapping schemes 
em table area, and common system 

as the first segment (memory mapping 
o three segments which need not be in 

schemes which use map file have 
nes commonly used by device service 

The third segment of all map 



...The task scheduler and SVC and XOP code 
...A device service routine (DSR). 

Figure 1-5 shows how the logical address space of map schemes is 

arranged. 
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One of the map file 1 schemes includes not only the system root in the 
first _ segment, "but also the file management and key indexed file 
handling code (i.e., file management and key indexed file code are 
physically located in memory immediately after the system root). This 
map scheme allows file management to map I/O buffers into its address 
space using the two remaining map segments. 

Other map 1 schemes include either a system task (memory resident or 
disk resident) or system common as the second segment. The third 
segment is available for use by the task. Figure 1-6 shows possible 
arrangements of map file 1 schemes. 

The link map of a generated system contains information on exactly 
which DX10 modules are included in each mapped segment. 
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1.2 HOW PARTS OP DX1 PIT TOGETHER 

The flow of control through DX10 follows many separate paths, 
depending on the action currently being performed. The remainder of 
this section traces these control paths separately, following the 
general order of events caused by the execution of a task. The order 
begins with SVC processing and the task bid and ends with task 
termination. 

1.2.1 SVC PROCESSING. 

Under DX10, supervisor calls are implemented as extended operation 
(XOP) 15. When an SVC is issued, control is passed via the XOP trap 
vector table to the SVC decoding routine, SVCINT, which is the XOP 
processor for XOP 15- This routine determines which SVC is desired by 
decoding the SVC code in the call block, and relinquishes control to 
the SVC processor. 

If the SVC processor is a queue server, control passes from SVCINT to 
the SVC buffering routine, SVCBUP. This routine buffers the call block 
into the system table area and queues the buffered call block on the 
proper queue, thereby activating the associated queue server task. The 
task that issued the SVC is suspended. 

If the SVC is for I/O (code 00), the SVC must go through yet another 
stage of decoding by the I/O supervisor, DXIOS. This routine buffers 
the user I/O data block and supervisor call block into the system table 
area, and determines whether the call is for file management (disk file 
I/O), file utility, or device I/O. Pile Management and Pile Utility 
calls are queued for the file management task or file utility task, 
respectively. Both are queue servers. Device I/O requests are handled 
by DXIOS and the device service routine directly, if the device is not 
busy. If the device is busy, the request is queued in the device queue 
for later processing. 

The return of control to the task that issued the SVC is different for 
queue serving SVC processors and nonqueue serving processors. Non- 
queue servers simply return control to the calling task via the system 
return point X0PRT1 , allowing the calling task to resume execution. 
Queue servers do not immediately return control to the calling task, 
but continue to process queue entries. When an entry has been 
processed, it is queued for the SVC cleanup routine, SVCCLN. SVCCLN 
unbuffers each entry from the system table buffer into the calling 
tasks memory, releases the system table area, and reactivates the task. 

Figure 1-7 shows the flow of control through the DX10 modules involved 
in SVC processing. 
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1.2.2 BIDDING A TASK. 

The process of "bidding or executing a task under DX10 involves 
building a task status block to describe the task, queueing the TSB for 
processing by the bidder task, TM$BID, and then queueing it for the 
task loader, as shown in Figure 1-8. 
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REQUEST / 
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(BUILDS 
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FOR BIDDER 
TASK 



BID 
QUEUE 



BIDDER 

TASK 

(TM$BID) 



QUEUE TSB 
FOR TASK 
LOADER 



WAITING ON 

MEMORY 

QUEUE 
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Figure 1-8 Bidding a Task 
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The first action taken by DX1 when bidding a task is to build a task 
status block (TSB). A TSB is a block of overhead data maintained by 
the operating system to describe each task currently running (either 
executing, waiting for CPU time, or rolled-out). The TSB contains 
pointers to other system overhead blocks associated with a task (e.g., 
logical device tables for each LUNO assigned by the task, procedure 
status blocks for any attached procedures), as well as other 
information describing the task to the operating system (see the 
section on data structures for more detail on task status blocks and 
procedure status blocks). From the time a task is bid until it 
terminates, the task is represented within DX10 by its TSB; all actions 
taken by the system in order to execute the task (e.g., roll-in, roll- 
out, memory allocation) reference the TSB. 

To build a TSB, the system routine TMBIDO calls memory management to 
reserve a block of memory from the system table area. It initializes 
some of the fields in the TSB, generates a run-time ID for the task, 
and then queues the TSB for further processing by the bidder task 
TM$BID. 

The bidder task is a memory-resident server. It dequeues a TSB from 
its queue, and fills in more fields (e.g., the task's priority) using 
data from the program file on which the task is installed. The bidder 
task also fills in the "family tree" pointers in the TSB. These four 
pointers link the newly bid task with other tasks, according to the 
structure shown in Figure 1-9- The parent task is the task that issued 
the Execute Task SVC to bid the task. If the task was bid from a 
terminal through an SCI command, SCI is the parent task. The brother 
tasks are other tasks that were bid by the same parent task. The 
oldest son is the first task that is bid by the task. This pointer is 
given a zero value when the task is first bid. 

Other pointers that are initialized by the bidder task are pointers to 
the procedure status blocks of any procedures associated with the task. 
A procedure status block serves a similar function for procedures as a 
task, although the pointers are not as complex (see Section 6, Data 
Structures, for more detail on PSBs) . If a procedure attached to the 
task being bid is not currently in memory (i.e., does not have a PSB) , 
the bidder task gets a block of system table area and builds the PSB 
for the procedure; the bidder task accesses the program file for 
necessary information. Figure 1-10 shows how TSBs and PSBs are linked 
by pointers under DX10. Note that PSBs may be linked with more than 
one TSB, since a single procedure may be attached to more than one 
task. 
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Figure 1-10 TSB/PSB Relationship 
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Finally, the bidder task queues the TSB on the waiting on memory queue, 
which is serviced by the task loader. The bidding task (parent task), 
which had been suspended while TMSBID processed the SVC, is 
reactivated. 

The scheduler and operating system provide a means for tasks to be bid 
from interrupt processors. The bid-task interrupt processor resets the 
interrupt, sets the bid-task-in-progress flag of the associated 

^njoi^aj. u.cvxCc oaDic, oa.ve» uric ±v u_L bflB uask to be D1Q \tne taSK to 

be bid must reside in the system program file), sets up the processor 
interrupt vector for handling multiple interrupts before the first bid 
is complete, sets the reenter me flag, and returns through the trap 
return module. The scheduler scans the PDT list for reenter me flags 
every time the scheduler runs (every 50 milliseconds), so that when the 
scheduler executes, the interrupt processor is reentered and the 
scheduler inhibit flag (TMSEXT) is cleared. 

When the processor is reentered, all lower interrupts are disabled. 
The interrupt processor resets the reenter me flag, initializes the 
registers required, and calls TMBIDO to bid the required task. Upon 
return to the interrupt processor from TMBIDO, the returned error code 
is checked. Appropriate action is taken when the error code is 
nonzero; when the error code is zero, the processor is exited. 

To exit the processor because of an error or bid complete, the bid- 
task-in-progress flag is reset and the interrupt entry vector is set up 
for processing subsequent interrupts. Exit is made by an RTWP 
instruction which returns to the scheduler for any necessary 
scheduling. 

The following list contains register definitions for a call to TMBIDO: 

RO » Error Return 

R1 ~ Installed ID/SVC flag 

SVC flag: ~ SVC call 

NOT « Not an SVC call 
R2 = Bid Parameter #1 
R3 - Bid Parameter #2 
R4 « Station ID/Program Pile LUNO 
R5-R9 * Not used 

R1 * Stack Pointer (The Scheduler Stack is used.) 
R1 1 as Branch and Link Return Address 
R12-R15 « Not used 

The following list contains register definitions upon return from 
TMBIDO: 

RO « Error Return 

R1 = Run ID/QUE - NO QUE flag (Bit 15) 
Bit 15: « Request not queued, 
1 * Request queued 
R2 s TSB address of bid task 
R3-R15 = Not used 
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The following error codes are returned from TMBIDO: 

» No error 

1 a Illegal station number on "bid task 

2 s No runtime task IDs available 

3 -No system table area available 

4 - Illegal program file LUNO 

1.2.3 SCHEDULING, LOADING, AND ROLLING A TASK. 

Once a task has been bid and a TSB has been built for it, that 
task must be loaded into memory before it can be scheduled for 
execution. The business of loading and executing multiple tasks is 
managed by the task scheduler in conjunction with the task loader and 
memory management. 

1 .2.3.1 Scheduling. 

Tasks running under DX10 may be found in a variety of states, 
including: active, suspended, queued for a SVC processor, and waiting 
for various types of I/O. TSBs of tasks that are waiting for CPU time 
(i.e., active tasks), and are in memory, are queued on the priority- 
ordered active queue. The task scheduler always picks the highest 
priority task off the active queue. Before actually giving the CPU to 
this task, the scheduler first checks the queue of tasks waiting on 
memory. 

This queue is a priority-ordered queue (highest priority first) of TSBs 
of tasks which are either rolled-out or have just been bid, and are 
waiting to get memory in order to execute. The scheduler determines if 
any task waiting on memory is of higher or equal priority to the task 
it has chosen from the active queue by searching the TbBs in tne 
waiting on memory queue. If a higher priority task is waiting, and the 
task loader is not busy, the scheduler gives the next time slice to the 
loader rather than the chosen task. If an equal priority task is 
waiting for memory, and the chosen task has already had a minimum 
number of time slices, the loader is likewise awarded the time slice. 
Otherwise, the chosen task gets the time slice. 

Figure 1-11 shows a simplified version of how the scheduler chooses a 
task to execute. The scheduler is described in more detail in Appendix 
E. 

1.2.3.2 Loading And Rolling. 

The task loader is responsible for loading tasks into memory and 
rolling them out. Tasks that are to be loaded may be either rolled-out 
tasks or tasks that have just been bid. The task status blocks of all 
tasks to be loaded are on the waiting on memory queue. The queue is 
sorted so that higher priority tasks are processed first. The queue is 
first-in, first-out for tasks of the same priority. 
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Tasks that are to be rolled-out by the task loader are tasks that have 
either been selected by memory management (see paragraph 1.2.3-3) to be 
rolled-out, but had TILINE I/O in progress, or issued a Get Memory SVC. 
Since TILINE I/O accesses the task's memory directly, the task could 
not be immediately rolled-out; therefore, memory management flags the 
TSB to indicate that it is being "quieted" (waiting for the I/O to 
complete). The TSB remains on the active queue until the I/O is 
complete 1 __at which time the scheduler queues the TSB onto the quieted 
queue. TSBs of" tasks which issue Get Memory SVCs are immediately 
queued on the quieted queue. All tasks that are on the quieted queue 
are rolled-out by the task loader. 

The task loader is a dedicated server of the quieted queue; that is, it 
is automatically bid when an entry is made on the queue. The loader 
may also be scheduled to execute when the task scheduler decides to try 
to roll a task into memory, although the loader does not "serve" the 
waiting on memory queue. Figure 1-12 shows how the loader processes 
the two queues . 

When the loader is executed, it first processes all of the entries on 
the quieted queue, rolling them out of memory, requeueing the TSBs onto 
the waiting on memory queue, and releasing the now vacant memory used 
by the tasks. When the quieted queue is empty, the loader checks to 
see if there is a task waiting on memory (i.e., a TSB on the waiting on 
memory queue). If not, the loader issues a Suspend Awaiting Queue 
Input SYC, returning control to the scheduler. 

If a task is waiting on memory, the loader checks for attached 
procedures, and tries to allocate memory for them (the allocation logic 
first checks to see if the procedure is already in memory) . If memory 
is found, the loader calls memory management to allocate memory for the 
task segment. If no memory is available, the load is left pending, and 
the loader checks to see if any more entries have been made on the 
quieted queue. At the ejid of the allocation phase, the loader checks 
to see if all of the memory required is still allocated. This might 
not be true if memory management has rolled out procedure 1 when 
allocating memory for procedure 2. 

If all of the memory is safely allocated, the loader loads the task and 
procedures (unless they were already in memory) from either the roll 
file (for roll-ins) or a program file (for initial bids). If the 
loaded task is flagged as memory resident, the loader assumes that it 
was part of the initial program load (system boot) and puts the task in 
a terminated state. Otherwise, the loader queues the task on active 
queue priority 0, slot 2 (head of the queue). This is done, regardless 
of the task's assigned priority, in order to insure that the task will 
get a time slice before it could be rolled-out by a higher priority 
task. 

After the task has been loaded, or some error has interrupted the load, 
the loader once again checks the quieted queue for entries. If there 
are any, the loader starts all over at the top of the cycle; otherwise, 
the loader suspends itself, returning control to the scheduler. 
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Figure 1-11 Simplified Plow of Scheduler 
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1.2.3.3 Memory Management. 

Available memory under DX10 is divided into system table area and 
user area (see Figure 1-1). All of this memory is dynamically 
UTooatet and deallotatd by J collection of nucleus routines called 
memory management. Memory is organized in four separate groups. 

. . .Free user memory 
...Allocated user memory 
...Free system table area 
...Allocated system table area 



The allocated blocks of system table area are the various system data 
structures, such as task status blocks, and are not all linked on a 
single list. Free blocks of system table area are all linked on a 
single list, headed by SAHEAD, an anchor contained in the DXIO data 
base module (described in Section 7). 

Free blocks of user memory are linked on a single list headed by 
TJAHEAD, another anchor in the data base module. Allocated blocks of 
memory, which may contain tasks, procedures, or file blocking ^ffers, 
are linked together on a time-ordered list. The time-ordered list 
(TOL) is maintained such that, whenever a block is accessed U-e., the 
task executes, or the blocking buffer is read or / ri * te * ^j' h * h *a 
removed from its current position on the TOL and relinked at the head 
of the list when it is no longer being used. Thus, the list is 
ordered, the first blocks on the list being the most recently used and 
the last blocks being the least recently used. Figure 1-13 shows how 
the time-ordered list is structured. 

Requests for system table area are serviced immediately by the table 
area allocating routine, MM$GSA. Since nothing in the system table 
area can be rolled (all system tables and device buffers are 
essential), the request is filled from available area only, and must 
immediately fail or succeed depending on how much table area is tree. 
The allocation routine does a first-fit, linear search of the free 
table area list, starting at the list header. If the search is 
unsuccessful, the routine scans the T.SB list, checking for disk 
resident queue servers which are suspended awaiting queue input. 11 
such a task is found, its memory is released, its TSB is deallocated, 
and the search for table area is restarted. 
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Requests for user memory (e.g., for tasks and procedures) are not 
always serviced immediately. The find memory routine, MM$FND, only 
processes one request at a time; further requests are queued until they 
can "be serviced. The find memory routine first searches the available 
memory list, using a first-fit search. If a free block of adequate 
size is found, the starting address of the block is returned to the 
requester. If no free block is available, the time-ordered list is 
scanned (by MMSSCN) for a rollable block of memory. 

The time ordered list (TOL) scan is from oldest (least recently used) 
block to newest (most recently used). Blocks are chosen for roll-out 
according to the following rules: 

1. Any buffer except the memory resident buffer; if the 
requester is buffer management, then the memory resident 
buffer may also be chosen. 

2. Tasks with lower priority. 

3. Higher priority tasks that have been suspended longer than a 
time threshold. 

4. Equal priority tasks that have received a minimum number of 
time slices since being loaded into memory. 

5. Any procedure with no currently attached tasks in memory. 

6. Tasks that have TILINE I/O in progress may be flagged for 
quieting, and subsequent roll-out, if the memory requester is 
not buffer management. 

7. Queue servers that are suspended for queue input. 

Tasks that may not be rolled-out are: 

1. Tasks that have an alternate task (see Section 6, Data 
Structures for a description of alternate tasks) . 

2. Tasks that are queued for the system overlay loader. 

3. File utility task (FUTIL) when it is accessing a directory. 

If the TOL scan is successful, the block chosen is rolled-out (if it is 
a task or procedure), written to its file (if it is a blocking buffer 
and has been modified), or simply released (if it is a queue server's 
memory or an unmodified buffer). The rolled block of memory is 
released from the TOL and put back on the free memory list. As blocks 
are added to the free memory list, they are merged with any immediately 
preceding or following blocks to reduce fragmentation. After a 
successful scan of the TOL, the find memory routine again searches the 
free block list. If a large enough block is still not available, the 
TOL is scanned again for another rollable block. Figure 1-14 shows ho^ 
user memory is found. 
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Figure 1-14 Find Memory Flow 
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1 .2.4 DEVICE I/O PLOW. 

When an executing task performs I/O, it must be done via an I/O SVC, 
and directed to a Logical Unit Number (LUNO) . The I/O SVC is decoded 
by the SVC decoder, as described in paragraph 1.2.1, and control passes 
to the I/O supervisor, DXIOS. The I/O supervisor determines from the 
I/O opcode that the call is not for file utility. It then searches the 
logical device table tree for the logical device table (LDT) 
corresponding to the LUNO to which the I/O is being directed. 



A logical device table (LDT) is a system data st 
for each LUNO assigned. The LDT describes the 1 
be assigned to a file or a device (see Section 6 
a detailed description of an LDT). All LDTs i 
in a hierarchy according to the type of LUNO 
(Figure 1-15). LDTs for task local LUNOs are 1 
anchored in the task status block for the task, 
linked to the terminal local LDTs for the termi 
is associated (if any), which are in turn linked 
LDTs for global LUNOs. 

When the I/O supervisor searches for the LDT of a LUNO, it searches for 
the LDT starting at the anchor in the calling task's TSB. The list is 
searched linearly through the task local LDTs, then the terminal local 
LDTs (if any), and finally the global LDTs, until an LDT for the 
desired LUNO is found. Note that this causes task local LUNOs to mask 
global or terminal-local LUNOs. 
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When processing an I/O request, the I/O supervisor checks the filing 
task to determine whether it has dynamic priority or not. It it does, 
the priority is updated according to the type of I/O being done. 

When the DSR finishes the I/O operation, it calls an ^-of-record 
(EOR) routine which increments a counter in the calling tasks T SB and 
places the TSB on the active queue. When the scheduler allots a time 
slice to the task, it checks the EOR count in the TSB. If the count is 
non-zero, the device drive task (DDT) is allowed to execute in the 
task's place. 

When DDT executes, it scans the list of physical device tables (PDTs) 
for a device that needs end-of-record processing. When such a device 
is found, DDT processes the end-of-record; it unbuffers the call blocK 
and data block (if any) into the calling task's memory (causing the 
task to be rolled-in first, if necessary), and activates the tasK. 
1 er processing an EOR for a device, DDT checks the device queue for 
queued I/O requefts. If a request exists DDT transf ^ control to the 
device service routine initial entry point. When the DSR finishes, it 
returns to DDT. When the DSR returns, or if the device queue is empty, 
DDT proceeds to the next PDT on the list. 

When DDT has checked all the PDTs, it suspends itself via a Suspend 
Awaiting Queue Input SVC, returning control to the scheduler. Figure 
Y-Te snlws a simplified flow of the DX10 logic involved in processing a 
device I/O SVC. 



1.2.5 FILE UTILITY PLOW. 

initial processing of a file utility SVC (code 0, opcodes >90 



The 



i>y 



through >9C) is similar to that for device I/O. The SVC " ^ded - 
SVCINT, and control passes to the I/O supervisor. The I/O supervisor 
determines from the "ninety" opcode that the call is for f ^ J^ 1 ^; 
The I/O supervisor preprocesses the file utility call by checking ior 
illegal opcodes, buffering the I/O call block, and queueing the 
buffered call block for the file utility task. The calling task is 
suspended w?th a state of "waiting on task driven SVC processor" (state 
>H). The file utility task, FUTIL, is a queue server and is 
automatically bid when an entry is placed on its input queue. 

When the file utility task gets CPU time, it dequeues an entry from its 
queue and processes that entry. File utility calls may be made m the 
old librarian or DX10 2.2 "FUR" formats. The file utility task 
converts such calls into DX10 3-0 file utility call format and then 
processes them normally. Normal processing (performed in module UC$) 
involves a table look-up of the correct processor for the specified 
file utility opcode (range >90 through >9C), and the transfer of 
control to that processor. When the processor finishes, it returns 
control to the file utility task. FU$ then queues the buffered call 
block for the SVC cleanup task, SVCCLN, which unbuffers the call block 
into the calling task's memory, and reactivates the task. Figure i -i f 
shows the flow of control for file utility SVCs. 
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Figure 1-17 File Utility Calling Processing 
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1.2.5-1 Assigning and Releasing LUNOs. 

Within DX10, a LUNO is represented by a data structure called a 
logical device table. Since the file utility opcodes include Assign 
LUNO and Release LUNO, file utility is responsible for building logical 
device tables and maintaining the LDT links. Whenever a LUNO is 
assigned, an LDT must_be built in the system table area, and its 
pointers defined. figure 1-18 shows the different pointers which may 
be set in an LDT. 

In addition to the LDT link which links all LDTs , in memory into the 
structure described in the device I/O section, all LDTs have a pointer 
to the physical device table of the device to which the LUNO is 
assigned. LDTs of LUNOs assigned to files point to the disk PDT of the 
volume (drive) that contains the file. All LDTs also have a pointer to 
the task status block of the task opening the LUNO. 

Pile LDTs (LDTs of LUNOs assigned to files) also have two additional 
pointers. All of the LDTs of LUNOs assigned to the same file are 
linked on a common list. Also, each file LDT has a pointer to the file 
control block (FOB) of the file to which the LUNO is assigned. A file 
control block is another data structure maintained in the system table 
area to describe a file (see Section 6). For every file that currently 
has LUNOs assigned to it (i.e., is being referenced), file utility 
maintains an FOB tree for all pathname components (i.e., higher level 
directories) of the files pathname. For example, if a LUNO is assigned 
to the file V0LUME4.USERO5. SOURCE. DEBUG, an FOB for USER05, SOURCE, and 
DEBUG will be in memory, linked together. The LDT for the LUNO 
assigned to DEBUG points to the DEBUG FCB, and is also linked on the 
list of LDTs for the file (see Figure 1-19). Note that the FCB for the 
volume directory (VCATALOG), an assumed component of every pathname, is 
always in memory when the volume is installed. A pathname can have a 
maximum of 49 bytes, which is 1 byte for the length of the pathname and 
48 bytes for the pathname itself. 

When a LUNO is released, file utility searches the FCB/LDT tree for the 
LDT of the LUNO being released. The LDT is delinked from the various 
lists it is on and released to the free system table area list; any 
blocking buffers associated with the LDT are released. If the LDT is 
linked to a file FCB, file management checks to see if any more LDTs 
are linked to the file. If not, the file must not be used currently, 
and the FCB is delinked from the FCB tree and released to the system 
table area. The search continues up the FCB tree. As long as an FCB 
has no LDTs linked to it (i.e., no LUNOs assigned to the file), and has 
no descendant FCBs (i.e., if the FCB represents a directory file that 
is not being accessed and has no cataloged files being accessed), it is 
delinked from the FCB tree, and the release LUNO search continues at 
the parent FCB. 
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1.2.5.2 Creating and Deleting Piles. 

Creation of a file under DX10 involves the following process: 

1 . The PCB tree of the directory under which the file is to be 
created is built in memory. For example, if the file 
V0LUMEA.USER05. SOURCE. DEBUG is being created, an FCB must be 
in memory for the VCATALOG, USER05, and SOURCE directories. 
This structure is necessary in order to access the directory 
V0LUMEA.USER05. SOURCE on the disk. A pathname can have a 
maximum of 49 bytes, which is 1 byte for the length of the 
pathname and 48 bytes for the pathname itself. 

2. Pile utility searches the disk directory to see if the file 
being created already exists. If so, an error is returned; 
otherwise, processing continues. 

3. A file descriptor record, which is a directory entry (see 
paragraph 4-3.4.2) for the file being created, is built in 
memory, and inserted into the directory on the disk. 

Deletion of a file involves a process similar to the one described 
above. The PCB tree must be built in order to access the directory in 
which the file is cataloged (note that the PCB tree may already by in 
memory). The file descriptor record in the directory is released and 
made available. The PCB representing the deleted file is released if 
it is currently in the system table area. In addition, the path up the 
PCB tree from the deleted file is searched for PCBs with no descendants 
(directories which are no longer being accessed). Any such PCBs are 
delinked from the PCB tree and released to the system table area. 

1.2.6 PILE I/O PLOW. 

The initial processing of a file I/O SVC is also similar to that 
for device I/O. The I/O supervisor determines from the I/O opcode that 
the call is for file management services. It then tests the I/O 
request to see if a "fast transfer" is possible. A request is eligible 
for "fast transfer" if the following conditions are met: 

..The file is not opened for unblocked I/O 

..The I/O is for a sequential or blocked relative 
record file 

..The operation is a read or write (not forced 
write) 

..The file is not currently being accessed 

..The record desired is already buffered in memory 
(i.e., it has recently been accessed and the 
buffer has not yet been destroyed). 
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If all of the conditions are met, control is transferred to the file 
management read or write routine, the desired I/O is performed directly 
between the file buffer in memory and in the calling task's data 
buffer, and control returns to the calling task. Thus, the I/O 
operation is performed by XOP level code, and the calling task is not 
suspended. If the conditions are not met, the call block is buffered 
into the system table area and queued for file management. The file 
management request queue is served by the number of replicas of the 
file management task, FM$TSK, specified during system generation. The 
file I/O queuing routine searches a list of file management tasks for a 
suspended task, and activates one if possible. 

FM$TSK is the main driver for file I/O processing. It dequeues an 
entry from the queue, and checks to see if the file is already being 
accessed by another FM$TSK. If so, it queues the request on a queue of 
I/O requests for that file, and dequeues another entry from the file 
management request queue. If not, FM$TSK checks the I/O opcode, and 
tranfers control to the correct processor. If the file being used is a 
key indexed file, control transfers to the key indexed file I/O driver, 
KI$BEG. When the processor returns, FM$TSK unbuffers the call block 
and key indexed file currency information, if necessary, into the 
calling task, and reactivates the task. It then checks for more queue 
entries, first on the queue for the same file, and then on the file 
management request queue. If more exist, it processes them. When the 
queue is empty, FMSTSK suspends via SVC >24- Figure 1-20 shows a 
flowchart of the top level of file I/O processing. 

Some of the opcode processors (e.g., FMOPEN for open calls) do no more 
than access the logical device table (LDT) assigned by the calling task 
to the file. The read and write processors work in conjunction with 
buffer management to transfer data between the disk file and user 
buffer. The following paragraphs describe the file buffering scheme 
used by DX10 file management. 
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1.2.6.1 Blocked Pile I/O. 

I/O operations to blocked files (any type of file except unblocked 
relative record - see Section 4 for a description of file types) are 
handled through a group of routines called buffer management. 

To access a specified logical record of a file, the file physical 
record that contains the desired logical record is read into a blocking 
buffer. These buffers are allocated from user memory, and are linked 
onto the time ordered list when not being used. The buffers are linked 
and delinked, read and written, created and released by buffer 
management routines. 

When file management receives an I/O request for a particular logical 
record of a file, it calls a buffer management routine to get the 
buffer that contains the physical record which in turn contains the 
desired logical record. If the specified physical record is already in 
a buffer on the TOL, the buffer management routine simply delinks the 
correct buffer and maps it into the file management task; if not, the 
buffer management routine creates a new buffer, reads the specified 
physical record from the file, and maps it into the file management 
task. 

The file management processor also calls a buffer management routine, 
BM$MAP, to map the calling task's data buffer into file management. 
Having both buffers mapped in allows file management to avoid using 
long distance instructions when transferring data between the two 
buffers. 

After the file management processor has completed transfering the 
specified logical record, it calls another buffer management routine to 
release the file blocking buffer, which is relinked onto the head of 
the TOL. 

The use of blocking buffers in DX10 is an attempt to reduce the actual 
number of disk accesses required to perform a given number of file I/O 
operations. Since buffers are not immediately released, but rather 
stay on the TOL until their memory is required by memory management, a 
read or write request to a blocked file record may be made to a buffer 
already in memory, rather than necessitating a disk access. 

1.2.6.2 Unblocked Pile I/O. 

I/O operations to unblocked files (i.e., program, image, 
directory, unblocked relative record files) do not use intermediate 
blocking buffers. The file management processor calls BM$MAP to map in 
the calling task's data buffer, and then calls the file management disk 
I/O routine, PM$I0, to transfer the record directly between the disk 
and data buffer. 
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1.2.7 TASK TERMINATION. 

There are four ways for a task to terminate execution: 

* Issue an End Task or End Program SVC 

* Issue a Suspend Awaiting Queue Input SVC (system tasks only) 

* Create an error and go into end action 

* Be killed by another task issuing a Kill Task SVC 

All terminated tasks, except tasks which are suspended awaiting queue 
input, have their memory released and their TSBs queued for the 
termination task, TMSDGN. 

TM$DGN performs such general clean-up actions as: 



..closes LUNOs opened by the terminated task 

..releases task local LUNOs assigned by the 
terminated task 

..delinks the TSB from its family tree structure 

..activates the parent task if specified 

..sends any error message to the system log 

..clears any breakpoints for the terminated task 

..releases the TSB, if the task is not memory 
resident . 



following paragraphs describe what happens to a task at 



!he 



termination. 



1.2.7.1 End Task/End Program SVC. 

The End Task and End Program SVCs are both processed by a routine 
in the module TM$FUN. This routine checks the TSB of the executing 
task (i.e., the task issuing the SVC) for any outstanding I/O. If any 
exists, it is aborted, and the task is left on the active queue in 
order to allow the device driver task to process the task's end-of- 
records. The kill flag in the TSB is set, to notify the task scheduler 
that the task has been terminated. 

When a task's kill flag is set, and it has no outstanding I/O, either 

the scheduler or the end task/end program routine queues the tasks TSB 

for processing by the termination task, TMSD3N. If the task is not 

memory resident, its memory is released. 
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1.2.7.2 Suspend Awaiting Queue Input SVC. 

This SVC is also processed by a routine in the TMSFUN module. This 
routine simply enters a state >24 in the task's TSB, and resets the 
task's PW and WP register values to restart it. The task's memory is 
not immediately released, nor is its TSB queued for the termination 
task. Since the task is not processed "by TM.*DGN, it should re] ease all 
task local LUNOs before issuing this SVC. 

1.2.7.3 Error Termination. 

When a task causes an internal error interrupt (e.g., address out of 
range, memory parity error), it is forced to go into end action. If 
the task has no end action, or when the end action terminates, the 
tasks memory is released and its TSB is queued for the diagnostic task. 

1 .2.7.4 Kill Task SVC. 

When a task is killed, it is forced into end action, and then queued 
for the diagnostic task. 
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SECTION 2 
ORGANIZATION AND STRUCTURE OP DX1 SOURCE LIBRARIES 



2 . 1 GENERAL 

This section is intended as a guide to help the user search a DX10 
source disk for a particular module. It contains a tabularized 
description of the top level directories and their contents. A disk 
map of the DX10 Operating System source disk is contained in the 
Product Documentation Package manual for the DX10 source (part number 
2250958-0001 ) . 

The DX10 source and object modules are cataloged under a directory 
structure that is generally organized as follows : 

The level one directories (directories under VCATALOG) break 
the DX10 code into specialized sections (e.g., task manager, 
disk-manager, GEN990, key indexed file processor). 

Each level one directory generally contains two sub- 
directories, OBJECT and SOURCE. 

The OBJECT and SOURCE directories contain the object and 
source modules of DX10 routines associated with the general 
function implied by the level one directory name (e.g., task 
management routines, memory management routines). 



2.2 TOP LEVEL DIRECTORIES 

Table 2-1 gives the names of the top level source directories 
(cataloged directly under VCATALOG) and a brief description of the 
contents of each one. 
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Directory Name 

ANALZ 

BATCH 

BDLINK 

DEBUGR 
DEVDSR 
DSCBLD 
DSCMGR 
DXIO 

DXLINK 
DXMISC 

DXUTIL 
PILMGR 

PUTIL 
GEN990 

GENPLINK 

KIFILE 

LINKER 
MEMMGR 



Table 2-1 Top Level Directories — Part 1 of 2 

Contents 



The routines that make up the system crash analyzing 
utility, ANALZ. 

Several SCI hatch command streams used to build a DX1 
system disk. 

Link Editor control streams, link maps, and linked 
object used by the disk build utility. 

The routines that make up the debugger. 

The device service routines for all supported devices. 

The routines that make up the disk build utility. 

The disk manager routines; the main driver is DM$TSK. 

The DX10 I/O routines, excluding file management and 
file utility; DXIOS is the main driver (i.e., processes 
all code SVCs.) 

Link Editor control streams, link maps, and linked 
object of various parts of DX10. 

Miscellaneous routines and modules within DX10, 
including: D$DATA, DXDAT2, SVC processors, boot 
loader. 

DX10 2.X to 5.1 disk conversion utility routines. 

Pile management routines; the main driver is FM$TSK. 
The routines for handling key indexed files and program 
files are cataloged elsewhere. 

Pile utility routines; the main driver is PUS. 

Routines and data files that make up GEN990, the system 
generation program; the main driver is GEN. 

Link Editor control stream, link maps and linked object 
used by GEN990 to generate a system. 

Key index file managing routines and overlays; the main 
driver is KISBEG. 

Batch streams, control file, and Link Editor routines. 

Memory management and buffer management routines. 
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Table 2-1 Top Level Directories — Part 2 of 2 
Directory Name Contents 



NOSHIP 
PATCH 
PGFILE 
SCI990 

SDSMAC 

SYSTEM 
SYSTSK 

TI 
TSKMC-R 

TXLINK 

UTCOMN 
UTDIRP 

UTDXTX 
TJTGENR 

UTLINK 
UTSVC 



Dummy debugger. 

Patch files for sysgen and system program file. 

Program file handling routines. 

Batch streams and control streams to generate SCI, and 
SCI routines. 

Batch streams and control streams to generate the macro 
assembler, and the assembler routines. 

Templates of system tables and data structures. 

Various system tasks, including: MVI , install/unload 
volume (I$V0L, U$V0L) , initialize disk flDSC), 
diagnostic task (TMDGN). 

The assembly language test program. 

Task management routines, including: scheduler, 
loader, rolling routines, etc. 

Link editor control streams, link maps, and object for 
the TX/DX file conversion routines. 

Common routines used by various DX10 utilities. 

Directory utility routines (e.g., for copy directory, 
delete directory, backup directory, restore directory). 

DX/TX file conversion routines. 

General utility routines, including DCOPY, SIS, STS, 
CKS, IDT, MAD, SAD, etc. 

Link Editor control streams, link maps and object for 
linking most of the utility routines". 

More utility routines, including Map Disk. 
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SECTION 3 
SYSTEM LOADERS 



3 . 1 GENERAL 

The software for loading and initializing the DX10 operating 
system includes: a program image loader on track 1 of all initialized 
disks, a specialized loader for loading DX10 images and initialization 
of various parts of the operating system, and a system restart task 
which further initializes DX1 and which bids any user specified 
restart task (GEN990 ID parameter). 

In addition, the new ROM bootstrap loader (multiwire - PN 9451 34-001 3; 
printed circuit - PN 945134-0014) which can load a program from cards, 
cassette, magnetic tape, or disk, is used to load the program image 
loader. 

The normal sequence for loading a system image is: 

1 . Initiate the boot loader (by pressing the HALT, RESET, and 
then LOAD buttons on the front panel) 

2. The boot loader loads the disk program image loader, starting 
at location >A0. 

3« The disk program image loader determines where the end of its 
address space (highest address) is, relocates itself to the 
high end of memory, then reads in the special system image 
loader, starting at location >A0. 

4. The system image loader relocates itself to the high end of 
memory, loads the DX10 image specified in the disk volume 
information (track 0, sector 0), initializes system 
variables, bids the system restart task, and transfers 
control to the operating system. 

5- The system restart task, executing under control of the 
operating system, performs more initialization of the 
operating system and then bids the user specified restart 
task, if one was specified when the loaded system was 
generated. 
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The following paragraphs describe each separate loader and restart task 
in detail, as well as options in the loading sequence that may be used. 



3.2 THE BOOT LOADER 

The "bootstrap loader which is contained in ROM, is capable ^ of 
loading a program from either cards, cassette, magnetic tape, or disk. 
The loader can be programmed to load from any of these media by 
inserting values in the boot workspace (memory locations >80 - >9F) via 
the front panel of the 990/10 computer. 

Location >80 is used to specify the loading device, according to the 
following rules: 

* If the content of >80 is positive, load from the card reader 
at the preferred location (CRU address >40) . 

* If the content is zero, load from a cassette at the preferred 
location (CRU address 00). 

* If the content is negative, load from the TILINE device 
(magnetic tape or disk) at the address specified in location 
>82. 

If the loading device is a TILINE device, locations >82 and >84 
are used to specify the TILINE address and unit select, respectively. 
The unit select value specifies which device on a multiple-device 
controller is to be used. For magnetic tape controllers, the following 
values should be used: 



>8000 


- 


unit 





>4000 


- 


unit 


1 


>2000 


- 


unit 


2 


>1000 


- 


unit 


1 



For disk controllers, the following values should be used: 



>0800 


- 


unit 





>0400 


- 


unit 


1 


>0200 


- 


unit 


2 


>0100 


- 


unit 


3 



The default values, which are inserted into these locations by pressing 
the HALT button on the front panel, cause the ROM loader to boot from 
disk unit at TILINE address >F800. Note that when loading from a 
disk, the ROM loader always loads the program image loader from track 
1; however, when loading from cards, cassette, or magnetic tape, it 
loads whatever program image is read from the device. 
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3-3 THE DISK PROGRAM IMAGE LOADER 

The loader SYSLD, which resides on track 1 of every DX10 3.0 formatted 
disk, is capable of loading any standalone program from an image file 
on disk into memory. After the program is loaded by the boot loader at 
location >A0, it relocates itself to the high end of its address space 
(e.g., the high end of 32K words). It then determines what program to 
load by using the volume information in sector of track on the 
system disk (see paragraph 4-2.1 for a description of the volume 
information) . 

The program to be loaded is chosen according to the following rules: 

1. If the diagnostic flag in the volume information is Y (i.e. 
non zero), the diagnostic task, which can be any standalone 
task, will be loaded, and the flag reset to N (zero). 

2. If no diagnostic is specified, the loader checks to see if 
the file pathname of either a primary or a secondary system 
loader is specified. If so, the image loader loads whichever 
system loader is indicated by the flag (0-load primary, 
1-load secondary, -1=?load secondary and reset flag to zero). 

3. If no system loader is specified, the image loader loads the 
system image indicated by the image flag, which is used in 
the same manner as the system loader flag. 

The program image loader normally loads a program image starting at 
memory location >A0. This default load bias is stored in the second 
word of the loader, and may easily be changed by a Modify Absolute Disk 
(MAD) command. Note that, since the image loader neither changes 
memory mapping nor uses long distance instructions, it always loads in 
its own address space. When the loader is booted by the ROM loader, it 
is always mapped into the first 32K words of memory. 



3.4 THE SYSTEM LOADER/ INITIALIZER 

The DX10 system loader, module STARTR, is normally located on file 
. SSLOADER. This program assumes it has been loaded starting at 
location >A0 by the program image loader, and relocates itself to the 
high-order 8K bytes of physical memory. It then determines the name of 
the operating system to be loaded from the program file . SSIMAGES, by 
reading the volume information on track 0, sector 0. The system select 
flag ' indicates which system image is to be loaded (0-primary, 
1«secondary, -1«load secondary and reset flag to zero). 

After obtaining the name of the system to be loaded, the system loader 
searches .VCATALOG and finds the program file, . SSIMAGES. It then 
loads the system image from disk, starting at location >A0. 
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After loading the system image, STARTR performs the following 
initialization functions: 

* Initializes the map files for all of the system segments. 

* Renames the disk drives (if necessary) to make the system disk 
DS01 . 

* Initializes memory "beyond the end of the loaded system to a 
constant pattern (>BOOB). 

* Initializes memory size parameters. 

* Initializes the interrupt and XOP trap vectors in memory 
locations >00 - >80. 

* Creates file control blocks and logical device tables for 
VCATALOG, the system program file, the system overlay file, 
and the roll file. 

* Enters the power up code of each device service routine in the 
system. 

* Loads memory resident procedures and bids memory resident 
tasks . 

* Initializes free memory pointers. 

* Bids the system restart task, SYSRST. 

After initialization, the system loader releases control to the task 
scheduler. 



3-5 THE SYSTEM RESTART TASK 

When the operating system starts up, the first task scheduled for 
execution is the system restart task, SYSRST. This task performs 
initialization functions that are easier to do under a running 
operating system than in the system loader. SYSRST also "bids the user 
specified restart task if there is one (the user restart task must he 
on the system program file, and is specified during system generation). 
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The initialization functions performed by SYSRST are: 

* Delete all temporary files on the system disk 

* Assign global LUNO >10 to the language program file, SSSDS 

* Assign global LUNO 1 to the foreground TCA file, S$FGTCA 

* Assign global LUNO 2 to the background TCA file, SSBGTCA 

* Assign global LUNO ^ to the master TCA library file, SSTCALIB 

* Enables the SCI bidding logic within the operating system 

* Bids the system log command processor to start file logging. 
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SECTION 4 
DISK ORGANIZATION 



4.1 DISK FORMAT 

Under DXIO, ail tracks on disks are initialized in one sector per 
record format. Note that this record is a disk characteristic and is 
not the same as the physical record size specified when creating files. 

DX10 disks are logically divided into allocable disk units (ADUs), as 
described in the DX1Q Operating System Systems Programming Guide . An 
ADU is defined to be an integral number of sectors on the disk, the 
number of sectors per ADU varying according to disk size (see table 4- 
1), such that the number of ADUs is less than 65,536 (i.e., each ADU on 
the disk can be addressed in a 16-bit word) and the sectors (ADU is 1 
or a multiple of 3). ADUs are numbered from zero, with the first ADU 
starting on track 0, sector 0. 

Table 4-1 Format Information for Supported Disks 





No. of 


No. of 


Sectors/ 


Bytes/ 


Disk Type 


Sectors 


ADUs 


ADU 


ADU 


DS10 


16320 


16320 


1 


288 


DS25 


77520 


25840 


3 


864 


DS31/DS32 


9744 


9744 


1 


288 


DS50 


154850 


51616 


3 


864 


DS200 


588430 


65381 


9 


2592 


CD1 400/32 










Removable 


52544 


52544 


1 


256 


Fixed 


52544 


52544 


1 


256 


CD1 400/96 










Removable 


52544 


52544 


1 


256 


Fixed 


262716 


43^86 


6 


1536 



4.2 PHYSICAL ORGANIZATION OF THE DISK 

To prepare the disk for use, surface analysis and initialization 
disk must be performed. Surface analysis is performed by using 
(Initialize Disk Surface) command. After execution of this c 
the disk state word in track zero, sector zero contains a value 
Additionally, bad tracks (physical imperfections) on the d 
indicated. Each bad track is indicated in pairs of words. The 
word indicates the first of any contiguous group of bad tracks, 
second word indicates the number of contiguous tracks. Initial 
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of a disk is performed by using the INV (Initialize New Volume) 
command. When a disk is initialized, the disk state word in track 
zero, sector zero, contains a value of three, indicating that the disk 
is now ready for use. Bad disk areas are indicated by ADUs in pairs of 
words. The first word contains the ADU address of the first of any 
contiguous group of bad ADUs. The second word contains the address of 
the last ADU in the group. 

All disks that have been initialized under DX10 have the following 
physical layout: 

* Track 0, sector — contains information about the disk 
volume, such as the volume name and pointers, to the volume 
directory (VCATALOG) . 

* Track 0, sector 1 — contains a list of bad (in the sense of 
physical imperfections) areas on the disk. Each entry is two 
words: the first word is the address of the first bad ADU; 
the second word is the address of the last bad ADU. A zero 
word terminates the list. 

* Track 0, sector 2+ — the remainder of track contains disk 
allocation information, in the form of bit maps. 

* Track 1 , sector 0+ — is reserved for the disk program image 
loader described in Section 2. 

* Track 1 , penultimate sector — a copy of track 0, sector 0. 

* Track 1 , last sector — a copy of track 0, sector 1 . 

* The remaining tracks are available for file allocation. 

The following paragraphs describe the track information in greater 
detail. 

4.2.1 VOLUME INFORMATION. 

The information contained in track 0, sector of all disks intialized 
under DX10 is called volume information. Figure 4-1 shows the format 
of the 140-byte block of information. 

The following is a list of the volume information contained in track 0, 
sector 0. Note that some fields have zero values when the disk is 
initialized. 
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Hex. 

Byte 

* * 

>oo ! I 

! VOLUME NAME j 

i j 

1 ! 

+ + 

>08 J NUMBER OP ADUs J 

+ + + 

>OA j BIT MAP START SECTOR j NUMBER OE BIT MAPS | 
+ . + 1 + 

>OC j - TRACK RECORD LENGTH | 

+ _ + 

Figure 4-1 Volume Information Format (VIF) — Part 1 of 4 
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>OE 


i 

i 






>10 


i 

i 
i 

i 




i 

i 

+ 


>16 


i 

i 




+ 


>18 


i 
i 




+ 


>1A 


i 

i 




+ 


>1C 


i 

i 



-+ 



>24 
>26 



>2E 

>36 

>3E 
>40 
>42 
>44 
>46 



+- 
i 

i 

+- 

i 

i 



+- 
i 

i 

+- 
i 

i 

+■ 
i 



PROGRAM IMAGE LOADER TRACK 
RESERVED 



NUMBER OP BAD ADUs 
PROGRAM IMAGE LOADER ENTRY POINT 
PROGRAM IMAGE LOADER LENGTH 



RESERVED 



PROGRAM IMAGE LOADER TRACK 
RESERVED 



PRIMARY SYSTEM IMAGE PILE NAME 



SECONDARY SYSTEM IMAGE PILE NAME 



SYSTEM IMAGE SELECT PLAG 
VCATALOG STARTING ADU 
VCATALOG PHYSICAL RECORD SIZE 
SECTORS/ADU 
CREATION DATE 






-+ 




-+ 



v 



v 



+ 



+ 



+ 



+ 



+ 



■+ 



Pigure 4-1 Volume Information Pormat (VIP) — Part 2 of 4 
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! ! 



PRIMARY PROGRAM FILE NAME 
i 



>52 ' 



+ ; 

i i 

i 



SECONDARY PROGRAM PILE NAME 
i i 

+ ; 

>5A ! PROGRAM PILE SELECT FLAG * J 

>5C ! ! 

PRIMARY OVERLAY FILE NAME ~ 

i__ 1 

>64 ! " "" I 

~ SECONDARY OVERLAY FILE NAME ' ~ 

i 

i i 

+ ; 

>6C ! OVERLAY FILE SELECT FLAG j 

> 6E | I 

I PRIMARY SYSTEM LOADER FILE NAME ~ 

! ~ 



+- 

SECONDARY SYSTEM LOADER FILE NAME 



>76 ! "" " "I 



i 1 

>7E [> SYSTEM LOADER SELECT FLAG j 

+ J 

>80 j j 

~ DIAGNOSTIC FILE NAME ~ 

! ~ 

t __ ; 



>88 ! DIAGNOSTIC SELECT FLAG j 

+ ; 

>8A i DEFAULT PHYSICAL RECORD SIZE | 

+ + f - ,V, -^ 

>8C j BAD ADU LIST STARTING SECTOR j \ tt>f !A '^ 



+ ; 

t { r 

+ ; 

Figure 4-1 Volume Information Format (VIF) Part 3 of 4 
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+ ™ ; " ~ t^' 

>8E ! TRACK SECTORS/RECORD i 

+ ._ _ + 

>90 ! I 

WCS PRIMARY PILE 

i 

i i 

; | 

>98 ! -I 

WCS SECONDARY PILE 

i 
i i 

; 1 



>AO ! WCS SELECT FLAG- 

+ 

>A2 j VOLUME INFORMATION COPIED FLAG 

+ 

>A4 | DISK STATE 



+ »+ 



Figure 4-1 Volume Information Format (VIP) — Part 4 of 4 



A6jO 



pbdcof to Ln ' 1 

{ - Cop'*-* 






■{- cooi e« 
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Hex. 

Byte Description 



>00 
>08 

>OA 



>OC 
>0E 



>2E 
>3E 



>42 



A 1-8 character volume name, blank filled to the right. 

Total number of allocable disk units contained in the volume. 
This field varies by disk type. 



The number of the sector on track in which the first bit mav 
resides. * 

>0B Total number of bit maps. 

The number of bytes per physical record (i.e., sector) on 
track 0. This value is also disk dependent. 

The number of the track that contains the disk program image 
loader. This field is initialized to one. 

>10 Reserved. 

>16 Total number of bad ADUs on the disk. 

>18 Entry point address of the disk program image loader 
Unitialized to >A4, the entry point of the loader when it is 
loaded at location >A0) . 

>1A Total length, in bytes, of the disk program image loader. 
>1C Reserved. 

>24 Second copy of the number of the track that contains the disk 
program image^ loader (initialized to one). 

>26 Reserved. 



The 1-8 character name of the primary system image file. Zero 
at initialization. 

Name of the secondary system image file. Zero at 
initialization. 

System select flag. Zero at initialization. 

>40 Number of the ADU in which the volume directory (VCATALOG) 
begins. 



Physical record size of the VCATALOG directory fil 
(initialized to >86 bytes). 



e 



>44 Number of sectors per ADU (disk dependent). 
>46 Disk creation date. 
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>4A Primary system program file name. 

>52 Secondary system program file name. 

>5A System program file select flag. 

>5C Primary system overlay file name. 

>64 Secondary system overlay file name. 

>6C System overlay file select flag. 

>6E Primary system loader file name. 

>76 Secondary system loader file name. 

>7E System loader select .fi-te". --tUa. 

>80 Diagnostic file name. 

>88 Diagnostic select flag. 

>8A Default physical record size for the disk (not implemented) . 

>8C Sector in track in which the load ADU list begins (equals 1 
for DX10 disks). (Not implemented). 

>8E Number of sectors per record on track (not implemented) . 

>90 Primary writable control storage (WCS) file name. 

>98 Secondary writable control storage (WCS) file name. 

>A0 Writable control storage select flag. 

>A2 Volume information copied flag. 

>A4 Disk state "XPS. T>©k1^ 

4.2.2 Allocation Bit Map 

To keep track of which areas on the disk are allocated and which areas 
are free r the DX10 disk manager maintains a bit map of allocated ADUs. 
The bit map is located on track of each disk, starting at sector 2 
and continuing through as many sectors as necessary. 

The bit map is divided into 128-word partial bit maps. Each partial 
bit map is located in a separate sector on track 0. The first word of 
each partial bit map contains the number of th ADU that begins the 
largest block of free disk space located in that part of the disk that 
is mapped by the partial bit map. Each bit in the remaining 127 words 
represents an ADU. If the bit is zero, the ADU is free; a one bit 
indicates that the ADU is allocated (or bad) . 
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Figure 4-2 shows a partial bit map. Note that, since each partial bit 
map contains 127 16-bit words of information, it maps 20^2 ADUs. 



BYTE 



RELATIVE ADU NO. OF LARGEST 
AVAILABLE BLOCK 



PARTIAL ALLOCATION BIT MAP 

BIT = 1 MEANS 
UNIT ALLOCATED 



2278128 



Figure 4-2 Partial Bit Map 



4-3 FILE STRUCTURES 



DX10 supports three file types: relative record files (block and 
unblocked), sequential files, and key indexed files. All file types 
on the^ unblocked relative record type, with extra system 



are based 



overhead needed to implement sequential and key' indexed files. In 
addition, there are three special usages of the relative record file: 
program files, directory files, and image files. 

In the following discussion of file types and file structures, a 
physical record of a file is the amount of data actually transferred by 
the operating system during an I/O operation to the file; a logical 
record of a file is the amount of information the user desires to 
transfer in an I/O operation. The ratio of the physical record size to 
the logical record size is called the blocking factor. 



939155-9701 



4-Q 



Texas Instruments 



Disk Organization 



System Design Document 



4.3.1 RELATIVE RECORD PILES. 

A relative record file is a file in which all logical records are a 
fixed length and each record can "be randomly accessed by its unique 
record number. Relative record files may be unblocked (logical record 
size equal to physical record size) or blocked (logical record size 
less than physical record size) . 

4.3.1.1 Unblocked Relative Record Piles. 

Each logical record of a file of this type occupies one physical record 
of the file. A physical record may be any integral multiple of 
contiguous sectors. Pile accesses require reading or writiog this many 
sectors (reads and writes of multiple contiguous sectors can be 
accomplished via one disk access). Records read from unblocked 
relative record files are transferred directly from the disk to the 
user buffer, without intermediate system buffering. When the user 
specifies a particular record of the file, the record number is 
converted by file management to an absolute allocable disk unit number 
and a sector offset within the ADU. The absolute disk address is then 
passed to the disk device service routine (VSR.) to perform the actual 
data transfer. The disk DSR converts the ADU and relative sector to a 
physical track and sector disk address to communicate with the disk 
controller hardware. 



Long Unblocked Relative Record 
Record Size > ADU Size 



LONG UNBLOCKED RELATIVE RECORD , RECORD SIZE > ADU SIZE 







t \ 


RECORD 
A 








/ 






J 

\ 




V 




ALL DATA 


ALL DATA 


ALL DATA 


1 I 


\ 








v 

AD 


UNUSED 

/ 




V 
ADU 


V 
ADU 


2278129 


U 
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unblocked Relative Record 
Record Size < ADU Size 



PHYSICAL 
A 



LOGICAL 



UNBLOCKED RELATIVE RECORD 
RECORD SIZE<ADU SIZE 



ALL DATA 



RECORD 1 



V 




2d 



ALL DATA 



p: 




A 



ALL DATA 



^ 



V 




k3 



RECORD 2 



RECORD 3 



2278130 



ADU 



UNUSED 
/ 



Note that each physical record must begin on a sector boundary and that 
a physical record that starts in te middle of an ADU may not span the 
ADU boundary. 

4-3.1.2 Blocked Relative Record Pile. 

These files are the same as unblocked except that multiple logical 
records may be stored in each physical record. Logical records may not 
span physical records. Records are transferred via intermediate 
blocking buffers which are furnished from the general pool of user 
space by buffer management. 



Blocked Relative Record File 



BLOCKED RELATIVE RECORD FILE 



PHYSICAL RECORD 1 



REC 1 


REC 2 


REC 3 


REC 4 


V? 



4 LOGICAL RECORDS 



UNUSED 



V 



"V 



2278131 



ADU 



REC 5 



PHYSICAL RECORD 2 



REC 6 



REC 7 



4 LOGICAL RECORDS 




UNUSED 



4.3.2 SEQUENTIAL FILES. 

Sequential files are blocked relative record files with variable length 
logical records. Logical records may span physical record boundaries 
regardless of ADU boundaries. When a logical record spans a physical 
record boundary, it is broken into partial records which are contained 
in separate blocks. The first word of each Dhvsical record has two 
tlags indicating whether the first logical record is continued from the 
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preceding physical record and whether the last logical record is 
contained 'in the following physical record. Set flag "bits (bit - 1) 
have the following meaning: 

Bit Meaning When Set 



First logical record in this physical record 
is continued from the preceding record. 

1 Last logical record in this physical record 
continues in the next record. 

Each logical record or partial record is preceded by a header word and 
followed by a trailer word. The content of the header and trailer is 
the number of bytes of user data between them. An end-of-file is 
signified by a zero length record (zero header and trailer). 

A special condition exists when a record or last partial record ends 
with only one or two words remaining in the physical block. Since 
there is not room for another partial record (header/data/trailer), the 
next record will begin in the following block. The last word of the 
current block contians the number in the last trailer plus the number 
of unused bytes (two or four). Figure 4-3 shows how a sequential file 
is arranged. 

Logical records of a sequential file may be blank-suppressed (i.e., the 
sequential file is created blank-suppressed). In blank-suppressed 
files, all double blanks are removed. A blank-suppressed logical 
record has the following format: 

1 . Header word 

2. Byte containing a count of words with double blanks* 

3. Byte containing a count of words with no double blanks* 

4. Data characters* 

5. Trailer word 

* Items 2 through 4 above are repeated as necessary. 
Figure 4-4 shows a blank-suppressed record. 
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BYTE 

2 
4 
6 
S 
A 
C 

E 
10 

15 

16 
18 
1A 
1C 

IE 
20 
22 
24 
26 
28 
2A 



PHYSICAL RECORD 






1 




LOGICAL RECORD DATA 


8 


8 


E 


LOGICAL RECORD 1 DATA 


E 


8 


LOGICAL RECORD 2 DATA 


8 



FLAGS 

RECORD HEADER 



RECORD TRAILER 



RECORD 1 HEADER 



RECORD 1 TRAILER 

RECORD 2 HEADER (PARTIAL) 



RECORD 2 TRAILER (PARTIAL) 



PHYSICAL RECORD 1 



LOGICAL RECORD 2 DATA 



LOGICAL RECORD 3 DATA 



LOGICAL RECORD 4 DATA 



FLAGS 

RECORD 2 HEADER (PARTIAL) 



RECORD 2 TRAILER (PARTIAL) 
RECORD 3 HEADER 



RECORD 3 TRAILER 
RECORD 4 HEADER 



} 



RECORD 4 TRAILER 



2 THIS WORD POINTS BACK TO EOF HEADER 
NEXT RECORD STARTS IN NEXT BLOCK 



Figure 4-3 Sequential Pile Format 
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$ 



RECORD HEADER 



RECORD DATA 



RECORD TRAILER 



t 



PHYSICAL RECORD 



THIS IS A B. S. RECORD 



1 



WORDS OF BLANKS, 1 WORD OF DATA 



2 WORDS OF BLANKS, B 16 WORDS OF DATA 



t 



THIS RECORD REPRESENTS THE 80-CHARACTER RECORD BELOW 



H THIS IS AB.S. RECORD 



< 52 BLANKS> 



2278133 



Figure 4-4 Blank-Suppressed Record 
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4.3.3 KEY INDEXED PILES. 

Key indexed files have variable length logical records that can be 
accessed either randomly, "by any one of up to 1 4 alphanumeric keys, or 
sequentially, in the sort order of any key. On the disk, a key indexed 
file with n keys is arranged as follows: 

* The first 1 8n+^5 physical records are the KIP log blocks. 
Before modifying any record within the file, it is written 
into a log block, to prevent data loss in case of an error 
{e.g., power failure) during the data transfer. In the event 
of such an error, the logged image is written back into the 
original file record, when the file is next opened, and the 
file operation may be retried. 

* The next n physical records are the roots of the balanced 
trees (B-trees) that are used to locate each logical record 
within the file by key. There is a B-tree for every defined 
key (i.e., up to 14 B-trees); therefore, there are n B-tree 
roots. 

* Following the B-tree root nodes are physical records that 
contain data as well as physical records that contain other B- 
tree nodes. 

The following paragraphs describe the structure of B-trees and data 
records in detail. 

4.3.3.1 B-Trees. 

B-trees are made up of a root node, branch nodes, and leaf nodes. Root 
nodes are just the first node of the tree. Leaf nodes are the nodes 
that contain pointers to the data records. Branch nodes are all the 
nodes between the root and leaf nodes. 

A B-tree, under DX10, is a multi-way (having multiple branches per 
node), balanced tree; that is, all leaf nodes are at the same level. 
DX10 B-trees may not exceed nine levels. Figure 4-5 shows a sample B- 
tree, in which the key values are single letters. 

Each node of a B-tree occupies one physical record of a key indexed 

file, and is called a B-tree block. Each B-tree block contains a few 

words of overhead and several pointer/key value pairs. Figure 4-6 
shows a B-tree block. 
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Hex. 

Byte 

* * 

>00 | BLOCK NUMBER j 

: i 

+ + 

>04 I COMMAND NUMBER | 

+ + 

>06 j SPACE REMAINING j 

+ _ + 

>08 j PREDECESSOR POINTER j 

! OR FREE CHAIN LINK j 

+— — ■ + 

>OC j SUCCESSOR POINTER J 

! i 

>10 ! NUMBER OE ENTRIES j FLAGS j 

+ + + 

>12 j SEQUENTIAL INSERT POSITION! SEQUENTIAL INSERT COUNTER! 

+ + . + — + 

>H ! BLOCK NUMBER | \ 

i ! POINTER 

+ _ + ; 

>18 ! INDEX (LEAF LEVEL ONLY) j \ 

| + __ + 

>1A ! j 

~ KEY VALUE 

! ! 

+ + 

! ! 

! ! 

* . . * 



Figure 4-6 B-Tree Block 



Hex. 
Byte 



Description 



>00 Physical record number of this B-tree block. This field is 
maintained so that, should a system crash occur while this 
file block is being modified, the logged image can be restored 
to the correct file record. 



>04 



The opcode of the file operation being performed, 
is also maintained for logging purposes. 



This field 
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>06 The number of available bytes remaining to be used in this B- 
tree block. 

>08 If this block is currently being used as a B-tree node, this 
field points to the preceding node on the same level (zero if 
this is leftmost node) . The address is a physical record 
number. If this block is available for use, this field points 
to the next available block (free blocks are kept on a linked 
list) . 

>0C If this block is a B-tree node, this field points to the 
following node on the same level; otherwise, this field is 
unused. 

>10 The number of pointer/key value pairs currently contained in 
this block. 



>11 Flags. Bit 7 is set (byte 17 * 1) if this B-tree block is 
leaf. 



a 



>12 This byte is zero when the block is initialized due to a B- 
tree split. When the first entry is made to the block, this 
byte contains the number of entries in the block that are 
greater than the new entry. (This applies to sequential 
placement only; otherwise, byte >14 is moved up here). 

>13 When the block is initialized due to a B-tree split, this 
value is the maximum entries that may be inserted in the block 
plus one. For each subsequent entry to this block, if the 
number of entries in the block that are greater than the new 
entry equals the number in byte >12, byte >1^> is decremented 
by one. When this B-tree block is about to split, if byte >13 
is zero, the lower 90$ of the entries are in one block and the 
upper 10$ in the other. Otherwise, the split is 50-50. (This 
applies to sequential placement only; otherwise, byte >15 is 
moved up here. ) 

>14 These six bytes are the first pointer. If this is a non-leaf 
node, the first four bytes contain the record number of a 
branch or leaf node and the last two bytes are meaningless. 
If this is a leaf node, the first four bytes contain a record 
number of a data record and the last two bytes contain the key 
ID of the logical record within the data record. 

>1A The key value of the first pointer /key value pair. 



The remainder of the B-tree block contains more pointer/key value 
pairs. These entries in a B-tree block are kept sorted in increasing 
order of key value (smallest key value is first entry). 

If the block is not a leaf entry, each pointer field points to 3g 
subtree that contains all key values less than or equal to the ke^|| 
value associated with the pointer. In fact, the highest key value 
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contained in the subtree is the key value associated with the pointer 
(as shown in the sample B-tree) . 

Further information on general B-tree structure is available in The Art 
of Computer Programming, Volume III by Donald Knuth. 

4.3.3.2 Data Blocks. 

All of the data records (logical records) of a key indexed file are 
contained in data blocks. A data block is a physical record of the 
file and contains a few words of overhead and several logical records, 
as shown in Figure 4-7. The word following the last logical record has 
a zero value. 
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Hex. 

Byte 

* +- 



>00 j BLOCK NUMBER 



+ 1 

>04 j COMMAND NUMBER i 

+ + 

>06 j SPACE REMAINING ! 

>08 ! OVERFLOW BLOCK OR ! 

j FREE CHAIN POINTER ! 

>OC j HIGHEST KEY ID USED ! 

+ +--+ 

>OE ! RECORD SIZE (1ST RECORD) ! ! 

| + NOTE 1 

>10 ! KEY ID i i 

+ + — + 

>12 ! i 

RECORD 



! i 

+ + 

| RECORD SIZE (2ND RECORD) ! 

J KEY ID I 

j 

RECORD 



NOTE 1 — Pour Overhead Bytes per Logical Record 
Figure 4-7 Data Block 



Hex. 

Byte Description 



>00 Physical record number of this block. This field is 
maintained so that, should a system crash occur while this 
block is being modified, the logged image can be restored to 
the correct file record. 

>04 The opcode of the current command. This field is also 
maintained for logging purposes. 
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>06 The number of bytes remaining in the physical record. 

>08 This block is used to link the block on the free block chain. 

>0C The highest ID assigned to any logical record with the block. 

>0E Size, in bytes, of the first logical record including this 
word. 

>10 The ID assigned to the first logical record. 

>12 First logical record. 

Whenever a data record is to be inserted in a data block, it is 
assigned an ID that is unique within the block. The data record is 
then inserted in the first available place in the block. 

4.5.4 SPECIAL RELATIVE RECORD FILES. 

In addition to the three basic file types, three special uses of the 
relative record file warrant description: program files, directory 
files, and image files. 

4.3.4.1 Program Piles. 

Program files are unblocked relative record files having a logical 
record size of one sector. The smallest sector size allowed is 256 
bytes. Figure 4-8 shows the format of a program file. The sections of 
information describing the contents of the program file (see Figure 4-8 
will not always start at the beginning of records or be in the same 
place for all program files. The following set of equations define the 
record number and the offset into the record of the beginning of the 
sections of information. In the equations, R designates a record and 
designates the offset. 

R1 = 1 
01 = 

((MAX # TASKS +2)/2) * >10) + 01 

R2 = R1 + 



>TW 

((MAX jt TASKS +2)/2) * >10 + 01 

02 = remainder of 

MOO 

(MAX # TASKS +1) * >10 + 02 

R^ = R2 + 

>100 

''MAX # TASKS +1 ) * >10 + 02 

03 = remainder of 

TTW 
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R4 - R3 + 



04 ~ remainder of 



R5 = R4 + 



((MAX # PROCS +2)/2) * >10 + 03 
>T00 
((MAX # PROCS +2)/2) * >10 + 03 
>100 
(MAX # PROCS +1 ) * >10 + 04 

Trm 



05 * remainder of 



(MAX # PROCS +1) * >10 + 04 



((MAX # OVLYS +2)/2) * >10 + 05 



R6 « R5 + 



06 s remainder of 



7TTO 

((MAX # OVLYS +2)/2) * >10 + 05 
TWO 



R7 « R6 + 



(MAX # OVLYS +1 ) * >10 + 06 



07 s? remainder of 



vtod 

(MAX ft OVLYS +1) * >10 + 06 
TTUG 



R8 s R7 + 



08 » remainder of 



((MAX # HOLES * 4) +2) + 07 

7TUD 

((MAX # HOLES * 4) +2) + 0^ 

yfOo 



If 08 is not equal to zero, then R8 « R8 + 1 



R1 ,01 
R2,02 

R3,03 
R4,04 
R5,05 
R6,06 
R7,07 
R8: 



Record number and offset for names of tasks. 

Record number and offset for task directory entries. 

Record number and offset for names of procedures. 

Record number and offset for procedures directory entrie 

Record number and offset for names of overlays. 

Record number and offset for overlay directory entries. 

Record number and offset for unused space directory. 

Record number of first image record. 
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The first record (record number 0) of a program file contains six bit 

maps. These bit maps, in order of occurrence within record 0, are for 

memory resident tasks, memory resident procedures, all tasks, all 
procedures, all non-replicatable tasks, and all overlays. 



*. 



.* 



! OVERHEAD RECORD j 
+ + 

1 I ' NAMES FOR TASKS J 
+ + 

R2:02 j DIRECTORY ENTRIES FOR TASKS \ 

+ + 

R3:03 ! NAMES FOR PROCEDURES j 

+ + 

R4:04 ! DIRECTORY ENTRIES FOR PROCEDURES ! 



+- 



i 
-+ 



R5:05 i NAMES FOR OVERLAYS ! 



+- 



+ 



R6:06 j DIRECTORY ENTRIES FOR OVERLAYS j 



R7:07 J AVAILABLE SPACE LIST | 

+ + 

R8 ! IMAGE FORMATS FOR TASKS, PROCEDURES ft OVERLAYS ! 
* * 

Figure 4-8 Program File Format 

When record zero is initialized, all the bits in the bit map are zero 
except the first bit in the tasks, procedures, overlays, and non- 
replicatable tasks bit maps (the bit maps occupying bytes >54->D3). 
The first bit of these is a one, restricting user tasks from allocating 
ID zero. 

Each bit map is 16 words by 16 bits per word, and thus is able to 
represent 256 IDs. A bit set to one indiates the ID corresponding to 
the bit position (i.e., through 255) is assigned to a task, 
procedure, or overlay segment that is installed in the file. Figure 4- 
9 shows the format of record zero of a program file. 
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Hex. 

Byte 

* . * 

>00 j OOOO i 

+ _ + 

>02 j i 



RESERVED («0) 



! ! 

+. . + 

>io ! ! 



RESERVED («0) 



! ! 

>H ! ! 

BIT MAP FOR MEMORY 
RESIDENT TASKS 

! ! 

>34 ! ! 

BIT MAP FOR MEMORY 
RESIDENT PROCEDURES 

! : 

>54 ! ! 

BIT MAP FOR ALL TASKS ~ 

i ! 



+ + 

>74 i ! 

BIT MAP FOR ALL PROCEDURES 



i i 

i 



i 

+ . + 

>94 ! ! 

BIT MAP FOR ALL NON-REPLICATABLE TASKS 



! i 

+ + 

>B4 ! ! 

BIT MAP FOR ALL OVERLAYS 



! i 

+ + + 

>D4 ! MAXIMUM NO. OF TASKS j 02 j 

+ + + 

>D6 ! R2 ! 

+ + + 

>D8 j MAXIMUM NO. OF PROCEDURES! 04 ! 

+ . + + 

Figure 4-9 Program File Record Zero — Part 1 of 2 
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+ + + 

>DA j R4 ! 

+ + + 

>DC j MAXIMUM NO. OP OVERLAYS j 06 | 

+ + : + 

>DE j R6 j 

+ + 

>E0 j MAX. NO. OP HOLES (TASKS, PROCEDURES, AND OVERLAYS) j 

+ + 

>E2 | 07 ! 

+ + 

>E4 j R7 ! 

+ ; + 

>E6 ! ! 

UNUSED (=0) 

i i 

i i 

* * 



Figure 4-9 Program Pile Record Zero — Part 2 of 2 

At program file creation time, the maximum number of tasks, procedures, 
and overlays contained in "bytes >D4, >D8 and >DC of record are 
defined "by the creator of the program file. The maximum number of 
holes, which equals the sum of the above three values, is used to 
calculate the number of bytes required in the overhead records for the 
available space list. This list is headed by a word that contains the 
number of entries in the list. The rest of the list consists of 2-word 
entries that describe the unallocated spaces (holes) in the image 
portion of the program file. Each entry contains the starting record 
number and the number of available records in each unused portion of 
the program file. These spaces appear when an image is deleted. This 
space is recorded to be used again if a new image is installed in the 
program file that is the same size or smaller than the one that was 
deleted. Adjacent images, when deleted, create only one hole. Figure 
4-10 shows the format of the available space list. 

The available space list uses the entire record, not 256 bytes of it as 
the other overhead records do. Therefore, if the list spans records, 
an entry is split across two records. (The first word of the entry is 
the last word of one record and the second word of the entry is the 
first word of the next record) . The available space list is 
initialized at the same time record is initialized. Its values are 
as follows: 
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* * 

j 1 | FIRST WORD 

+ + 

j R8 j SECOND WORD 

j FFFF-R8 ! THIRD WORD 

* * 

R8 is the first record following the available space list. 



+ 



+ 



+■ 



NUMBER OF ENTRIES 



-+ 



SECTOR NUMBER 
SECTORS AVAILABLE 



■+ 



+ — + 



+- 



+- 



SECTOR NUMBER 
SECTORS AVAILABLE 



ENTRY 1 
i 



+ — + 



+ ENTRY n 
i 



Figure 4-10 Program File Available Space List 



The maximum number of records permitted in a program is FFFF. Thus, 
the maximum number of image records permitted in a program file is FFFF 
minus the number of overhead records. The actual image of a task, 
procedure, or overlay must start on a record boundary in the program 
file. If the segment has a relocation bit map, it begins at the first 
word following the program segment image. 

The task, procedure, and overlay name blocks in the program file 
contain the names of all tasks, procedures, and overlays installed in 
the program file. A name is eight bytes long, blank-filled to the 
right. The names are placed in the position in the name block that 
corresponds to the ID assigned to that segment. For example, if task 
CENTX is assigned ID 1, the name GENTX is entered in bytes 8-15 (second 
position) of the task name block. 

The task, procedure, and overlay directory blocks in the program file 

contain information about all segments installed in the program file, 
as well as pointers to the segment images. Each directory is 16 bytes 

long. The figures that follow show the formats of the program file 

directory entries, with the field description following their 

respective formats. Figure 4-11 shows the format of the task directory 
block. 
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Hex. 
Byte 



>00 
>02 
>04 
>06 
>08 
>OA 
>OC 
>OE 
>10 



LENGTH OP TASK SEGMENT 
FLAGS 



I 




RECORD NUMBER 






1 

1 




DATE INSTALLED 






1 

1 




LOAD ADDRESS 






1 

1 


OVERLAY LINK 


i 

i 


PRIORITY 




1 

1 


PROC 1 ID 


i 

i 


PROC 2 ID 




1 
1 
*- 




TASK LENGTH 







+ 



+ 



Hex. 
Byte 

>00 

>02 



>04 



Figure 4-11 Task Directory Block 



Description 



Length of task segment in bytes. Length of task root plus the 
length of the tasks longest overlay path. 

Flags, which mean the following when set: 

Bit Meaning When Set 



"Hr 



Privileged 

System 

Memory resident 

Delete protected 

Replicatable 

Procedure 1 is on the system program file 

Procedure 2 is on the system program file 

Directory entry in use 

Overflow 

Writable control store 

Execute protected 



8 

9 

10 

11-15 Unused (set to zero) 



Record number. Logical record number of the start of the task 
image in the program file. 
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>06 



Date installed. Date is in the format: 



Bit Meaning 



0-6 
7-15 



Year (Displacement) 
Julian date 



>08 



>0A 



>0B 
>0C 
>0D 
>0E 

h 



Load address. Relative starting address within a mapped task 
segment. Must be on a beet boundary. 

Overlay link. The ID of the most recently installed overlay 
associated with the task. Each overlay entry is in turn 
linked to the next entry so that tasks can be associated with 
their overlays when status or delete commands are executed. A 
value of is used to terminate the list. 

Priority of the task. 

Procedure 1 ID. 

Procedure 2 ID. 

Length (in bytes) of the difference between the last defined 

location and the first defined location of a task. If a BSS 

is the last instruction in the task, its length is not 
included in this value. 



Figure 4-12 shows the format of the Procedure Directory Entry. 



Hex. 
Byte 



>00 



>02 



>04 



>06 



>08 



>0A 



>10 * 



LENGTH OF PROCEDURE SEGMENT 
FLAGS 



RECORD NUMBER 
DATE INSTALLED 




Figure 4-12 Procedure Directory Entry 
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Hex. 

Byte Description 



>04 



>00 Length of procedure segment in bytes. 

>02 Flags, which mean the following when set: 

Bit Meaning When Set 

Unused (set to zero) 
Memory resident 
Delete protected 
Unused (set to zero) 
Directory entry in use 
-4a&k-8j*^ Unused (set to zero) 

9 Writable control store 

10 Execute protected 
,11_^_ Write protected 

12-15 Unused (set to zero) 




Record number. Logical record number of the start of the 
procedure image in the program file. 



>06 Date installed. Date is in the format: 

Bit Meaning 



0-6 Year (Displacement) 
7-15 Julian date 

>08 Load address. Relative starting address within a mapped 
procedure segment. Must be on a beet boundary. 

>0A Unused. 

>10 * 

Figure 4-13 shows the format of the Overlay Directory Entry. 
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Hex. 
Byte 



>00 



>02 



>04 



>06 



>08 



>0A 



>0C 



1 


LENGTH OF OVERLAY SEGMENT 


1 


FLAGS 


1 


RECORD NUMBER 


1 


DATE INSTALLED 


1 


LOAD ADDRESS 


1 


OVERLAY LINK | TASK ID 




UNUSED (=0) 



Hex. 
Byte 



Figure 4-13 Overlay Directory Entry 



Description 



>00 
>02 



>04 
>06 



>08 
>0A 



Length of overlay segment in bytes. 

Flags, which mean the following when set: 

Bit Meaning When Set 

Relocation bit map is present 

1-2 Unused (set to zero) 

3 Delete protected 

4-6 Unused (set to zero) 

7 Directory entry in use 

8-15 Unused (set to zero) 

Record number. Logical record number of the starting address 
of the overlay image in the program file. 

Date installed. Date is in the format: 

Bit Meaning 



0-6 Year (Displacement) 
7-15 Julian date 

Load address. Relative starting address within a mapped 
overlay segment. Must be on a beet boundary. 

Overlay link to the next overlay. 
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>0B Task ID of associated task. 
>0C-0F Unused (set to zero) . 
>10 * 

4.3.4.2 Directory Files. 

Directory files are unblocked relative record files and always have a 
record length of one sector. Record of the directory file contains 
an overhead record. The remaining records in the file may contain one 
of the following types of data blocks: 

* File Descriptor Record (FDR) — every file cataloged in the 
directory is represented by an FDR, which describes the file 
and its location on the disk. 

* Alias Descriptor Record (ADR) ■ — every alias of a file 
cataloged in the directory is represented by an ADR, which 
gives the location of the file and points to the FDR of the 
actual file. 

* Key Descriptor Record — each key indexed file cataloged in 
the directory is represented by an FDR, which in turn points 
to a key descriptor record. The key descriptor record 
describes all of the keys (1-14) that are defined for the 
file. Note that the use of the key descriptor record implies 
that each key indexed file cataloged in a directory uses two 
directory entries. 

Figure 4-14 shows the general structure of a directory file. Entries 
are made in the directory file by hashing the name of the file being 
entered. The hash algorithm results in a record number from one 
through n, where n is the last record in the directory file. 

Figure 4-15 shows the hash algorithm. If the directory file record is 

unused, an FDR for the file being inserted is placed in that record. 

If the record is already used, a free record is found by a linear 
search from the hashed record. 
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RECORD NO. 

1 



OVERHEAD RECORD 



U 



IRECTORY ENTRIES 



2278135 



Figure 4-14 Directory Pile Structure 
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2278107 



f HASH J 



KEY- 1 

I 1 



C 

NAME(I) 



YES 




KEY- 

((KEY*C)MOD N)+t 



1- I + 1 




NO 



YES 



( EX ' T ) 



WHERE 

N = NUMBER OF RECORDS IN 
THE DIRECTORY LESS 1 . 



Figure 4-15 Computing Hash Kej 
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If the file being inserted is a key indexed file, another directory 
record must be found to contain the key descriptor record. This record 
is found by searching linearly from the file descriptor record for the 
file. The key descriptor record is inserted in the first available 
directory record following the file descriptor record. 

The different types of directory records are described in the following 
paragraphs. 

The directory overhead record (record of all directories) contains: 

* The maximum number of records (entries) in the directory. 

* The number of currently defined files. 

* The number of available records (entries). 

* The filename of the directory. 

* The level number of the directory in the disk hierarchy 
(VCATALOG) is level 0) 

* The filename of the parent directory. 

* The default physical record length. 

Figure 4-16 shows the format of a directory overhead record. 
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Hex. 
Byte 



>00 j DORNRC — NUMBER OP RECORDS IN DIRECTORY ! 

+ _j 

>02 j DORNFL ~ NUMBER OP PILES IN DIRECTORY ' 

+ _! 

' vi r I jJ\J±\iAt\R JNu/lJ5Ji/n Or AVAlJjABl/E KJUUUKJjy [ 

>06 JDORTPC — NUMBER OP TEMPORARY PILES CURRENTLY~DEFINEdI 
+ . 



>08 



>1C 



>40 



* 



DORDNM — PILE NAME OP THIS DIRECTORY 
(8 ASCII CHARACTERS) 



>10 | DORLVL ~ LEVEL NUMBER OP DIRECTORY 

+ . . mmm _ 

>12 ! 



DORPNM — PILE NAME OP PARENT 
(8 ASCII CHARACTERS) 



>14 ! 

+ . 

>1A ! DEFAULT PHYSICAL RECORD LENGTH 



■+ 
i 

i 

-+ 



RESERVED 



! 



Figure 4-16 Directory Overhead Record Format 



.* 
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Each file cataloged under the directory is represented by a file 
descriptor record. Figure 4-17 shows an FDR. 

Hex. 
Byte 



>00 
>02 
>04 

>0C 



>10 


>12 


>14 


>16 


>18 


>1A 


>1C 


>1E 


>20 


>24 


>28 



+ 



+ 



+ 



+ 



+■ 



+- 



+■ 



+■ 



+■ 



+- 



-+- 



FDRHKC — HASH KEY COUNT 



FDRHKV -- HASH KEY 



FDRFNM — FILE NAME 
(8 CHARACTERS) 



FDRPSW — PASSWORD (4 CHARACTERS) 
(NOT IMPLEMENTED) 



FDRFLG — FLAGS 



FDRPRS — PHYSICAL RECORD SIZE 



FDRLRS — LOGICAL RECORD SIZE 



FDRPAS — PRIMARY ALLOCATION SIZE 



FDRPAA — PRIMARY ALLOCATION ADU 



FDRSAS — SECONDARY ALLOCATION SIZE 



FDRSAA — OFFSET TO SECONDARY ALLOCATION TABLE 



FDRRFA — RECORD NUMBER OF FIRST ALIAS 



FDREOM — END OF MEDIUM LOGICAL RECORD NUMBER 



FDRBKM — END OF MEDIUM BLOCK NUMBER 



FDROFM — END OF MEDIUM OFFSET 



-+ 
i 

i 

-+ 



i 

i 

■+ 
i 

i 

-+ 
i 

i 

-+ 
i 

-+ 



+- 



■+ 
i 
i 
i 

! 

- + 

I 
I 
I 

I 

- + 

I 

I 

- + 



Figure 4-17 File Descriptor Record — Part 1 of 2 
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>2A 

>2E 
>30 

>34 
>36 

>3C 



+- 
i 

\ 
i 

+- 

i 

i 

+- 

i 

i 

+- 

i 

i 

+- 
i 



>42 


i 

i 




+ 


>44 


i 
i 




+■ 


>46 


! 
i 




+ 


>48 


1 
1 




+ 
1 
1 




1 

1 

+ 
1 




1 

+ 


>84 


1 

1 




* 


>86 


* 



FDRFBQ — FREE BLOCK QUEUE HEAD 



FDRKDR — RECORD NUMBER OP KEY DESCRIPTORS 



PDRUD — RESERVED FOR LAST UPDATE DATE 



FDRCD — RESERVED FOR CREATION DATE 



■+- 



FDRAPB — ADUs/BLOCK | FDRBPA — BLOCKS/ADU 

. . , — + 

FDRMRS — MINIMUM RECORD SIZE 



FDRSAT — SIZE OF SECONDARY ALLOCATION 
STARTING ADU OF ALLOCATION 



SIZE OF SECONDARY ALLOCATION 
STARTING ADU OF ALLOCATION 



■+<■ 

i 



FDRBTR — BLOCK NUMBER OF B-TREE ROOTS 
FDRSBB — BLOCK NUMBER OF FIRST BUCKET 
FDRTNB- — TOTAL NUMBER OF BUCKETS 



i 

■+ 
i 
i 

-+ SEE 

j NOTE 1 

i i 

■+ ! 



•+<--+ 



-+ 
i 

i 

-+ 
i 



•+<■ 



-+ 

i 
i 

-+ 

i 



SEE 
NOTE 2 



-+ 
i 

i 

-+ 
i 

i 



■+ 



NOTE 1 — Used only for key indexed files. 

NOTE 2 — Secondary allocation table (up to 16 allocations). 



Figure 4-17 File Descriptor Record — Part 2 of 2 
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Hex. 
Byte 

>00 



>02 



Field 
Name 



FDRHKC 



FDRHKV 



>04 FDRFNM 
>OC FDRPSW 
>10 FDRFLG- 



Description 

Hash Key Count. The number of file descriptor 
records (which may or may not include this one) that 
are present in the directory that hashed to this 
record number. 

Hash Key. The result of the hash algorithm for the 

file name actually covered in this record. The 

value might not be this record number since the data 

may have arrived here via the linear search used 
when the hashed address is occupied. 

Pile Name. Eight characters. 

Password. A future feature. 

Flags as follows: 

Bit Meaning 

0-1 File usage flags: 

00 No special usage 

01 Directory 

10 Program File 

1 1 Image File 

2-3 Data Format: 

00 Binary 

01 Blank suppressed 

10 Reserved for ASCII ft print form control 

1 1 Reserved 

4 Allocation type: 

Bounded 

1 Unbounded 

5-6 File type: 

00 Reserved (for device) 

01 Sequential 

10 Relative record 

1 1 Key indexed 

7 Write protection flag: 

Not write protected 

1 Write protected 

8 Delete protection flag: 

Not delete protected 

1 Delete protected 
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>12 


PDRPRS 


>H 


PDRLRS 


>16 


PDRPAS 


>18 


PDRPAA 


>1A 


PDRSAS 


>1C 


PDRSAA 



>1E 



>20 



PDRRFA 



PDREOM 



>24 FDRBKM 
>28 FDROPM 



9 Temporary file flag: 

Permanent flag 

1 Temporary flag 

10 Blocked file flag: 

Blocked 

1 Unblocked 

11 A 1 .? ^„ 4?-|__. 

i i Axxcio -L_L<ag; 

Not an alias 

1 An alias file name 

12 Force write flag: 

Write "buffers when memory is required 

1 Write buffers when updated 

13 Reserved for FCB changed flag (see 6.4) 
14-15 Reserved 



Must be an even 
Must be an even 



Physical record size in bytes, 
number. 

Logical record size in bytes, 
number if the file is unblocked. 

Primary allocation size in ADU. 

Primary allocation starting ADU number (starting 
disk address) . 

Secondary allocation size in ADU. 

Offset into this FDR of the secondary allocation 
table, if any. No secondary allocation table is 
denoted by 0. Secondary allocations are present 
only for unbounded files. 

Record number with the directory of first alias 
name. Piles may be known by alias names. The alias 
names are noted in the directory in alias descriptor 
records. These alias descriptor records are chained 
to the actual PDR and each contains a pointer back 
to the actual PDR. 

The logical record number of the end of medium. The 
end of medium is the end of the last space allocated 
to the file. 

The logical block number of the end of medium. A 
logical block is the same as a physical block. 

The offset into the end of medium block of the 
logical record following the end of medium record. 
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>2A 



PDRFBQ 



>2E 



PDRBTR 



>30 


PDRSBB 


>32 


PDRTNB 


>34 


PDRKDR 



>36 



FDRUD 



>3C 



FDRCD 



>42 


FDRAPB 


>43 


FDRBPA 


>44 


FDRMRS 



>46 



FDRSAT 



Block number of the first block in a queue of key 
indexed file free (unused) blocks. Each block 
points to the next block in the queue (a block is a 
physical record of the file). Only used for key 
indexed files. 

The block number for the B-tree root block of the 
primary key. The block following this is the KIP 
root block for key 2, etc. This field is also the 
total number of blocks that can be used for logging. 

The block number for the first KIP bucket. 



The total number of buckets in the KIP file. 

Record number of the directory file 
containing descriptions of the KIP keys. 



record 



Date of the last update to this file. The date is 
made up of three words. Word 1 contains the binary 
value of the year. Word 2 contains a value that is 
two times the number of days (counting from the 
beginning of the calendar year); the least 
significant bit is the most significant bit of word 
3 of the date. Word 3 contains the number of 
seconds from the beginning of a day. 

Creation date of the file. The date is made up of 
three words. Word 1 contains the binary value of 
the year. Word 2 contains a value that is two times 
the number of days (counting from the beginning of 
the calendar year); the least significant bit is the 
most significant bit of word 3 of the date. Word 3 
contains the number of seconds from the beginning of 
a day. 

The number of ADUs per physical record. 

The number of physical records per ADU. 

The minimum size that a key indexed file logical 
record can be and still contain all of the keys 
defined. 

The secondary allocation table, which contains 16 2- 
word entries. The first word of an entry contains 
the size, in ADUs, of the secondary allocation. The 
second word contains the starting ADU of the 
allocation. The table allows up to 1 6 files, and is 
only used if the file was created expandable 
(unbounded). The entry fields are filled in by file 
management as the file is expanded. 
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llles c ^ n be given other names, each name being a separate alias. Each 

alias is hashed to find an entry in the directory just like a file 

name, and an alias descriptor record (ADR) inserted in that entry. The 

ADR points to the real file. It also points to the next alias for the 
file. Figure 4-18 shows the format of an ADR. 

Hex. 
Byte 



>00 



>0C 



#. 



i 

i 

+- 
>02 j 

+- 
>04 j 



ADRHKC — HASH KEY COUNT 
ADRHKV — HASK KEY VALUE 



ADRFNM — PILE NAME 



ADRPSW — PASS CODE 



-+ 
i 



>10 



>12 



+- 
i 

i 

+- 

>U ! 

+- 
>16 ! 

+- 
>18 | 

+- 
>1A | 

+- 



>1C 



>1E 



>20 



>22 



ADRFLG — FLAGS 



PHYSICAL RECORD SIZE 



LOGICAL RECORD SIZE 






PRIMARY ALLOCATION SIZE 



PRIMARY ALLOCATION ADDRESS 
SECONDARY ALLOCATION SIZE 



SECONDARY ALLOCATION ADDRESS 



ADRRNA — RECORD NUMBER OF NEXT ALIAS 
ADRRAF — RECORD NUMBER OF ACTUAL FILE 



UNUSED 



-+ 
i 
i 

-+ 

! SEE 



NOTE 1 



■+<--+ 



>86 



NOTE 1 — Used to maintain ADR for compatibility, 
Figure 4-18 Alias Descriptor Record 
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Hex. 


Field 


Byte 


Name 


>00 


ADRHKC 


>02 


ADRHKV 



>04 



ADRFNM 



>OC 



>10 



ADRPSW 



ADRFLG 



>12->1D 

>1E ADRRNA 



>20 

>22->85 
>86 



ADRRAF 



Description 



Hash Key Count. The hash key count is the same as 
in the file descriptor record. 

Hash Key Value. The hash key value is the same as 
in the file descriptor record. 

File Name. The file name given in this item is an 
alias name for the file. In other words, it is a 
secondary name by which a previously defined file 
will also be known. The primary name for a file is 
supplied in the file descriptor record; secondary 
names are documented in alias descriptor records. 



Passcode. Space is provided 
implementation of password codes. 



for 



future 



Flags. The flag values are the same as provided in 
the file descriptor record. Note that the flag for 
alias is set to a one in this particular record. 

These fields are not used. 

Record Number of Next Alias. This is a pointer 
chaining forward to another alias descriptor record 
for the same file, if any exists. A value of zero 
is provided to indicate the end of the chain; i.e., 
no more alias descriptor records exist for the file. 

Record Number of Actual File. This is a pointer to 
the directory file record containing the file 
descriptor record for this particular file. 

Unused. These bytes may contain non-zero values, 
but they are not used. 



A key descriptor record is used only for key indexed files. _ It 
describes the keys (up to fourteen) used to access records in the file. 
When a key indexed file is created and its keys are defined, a file 
descriptor record is hashed into the directory. File utility then 
performs a linear search for an unused directory record, starting from 
the file descriptor record. The key descriptor record is placed in the 
first available directory record. Figure 4-1 Q shows the format of a 
key descriptor record. 
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Hex. 
Byte 



>00 



>02 



\r\A 



>06 
>08 
>OA 
>0C 

>3C 

>3E 
>40 



Hex. 
Byte 



■+- 



HASH KEY COUNT 



-3 



NOT USED 



NUMBER OP KEYS 



-+■ 



FLAGS 



CHARACTER COUNT OP KEY 1 



OFFSET TO KEY 1 



FLAGS 



+ 



+ 



+ 



+< — + 

SEE 
NOTE 1 



i CHARACTER COUNT OF KEY 14 

+ . . 

OFFSET TO KEY 14 



+<--+ 



+ 



NOTE 1 — Por the primary key; repeat for each 
secondary key. 



Figure 4-19 Key Descriptor Record 



Description 



>00 
>02 

>04 
>06 



Hash Key Count. This is the same as described for the file 
descriptor record. 

Hash Key « 3. This field ig similar to that provided with 

lT^ f l + u d f^iptor record. The value of -3 is given to 
indicate that this record is a key descriptor record and, 
therefore, is unavailable for use as a file descriptor record. 

Not used. 

The number of unique keys defined for this key indexed file. 

iVi ere ml° a maximum of H keys available for any key indexed 

1 lie. There must be at least one key, the primary key. Keys 
2-14, if any, are secondary keys. 
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>08 Flags, as follows: 

Bit Meaning When Set 

0-3 Must be zero 

4 File was created by a system using the 
sequential placement scheme (primary key only) 

5 Of a secondary key is set to 1 if the key 
value need not always be present 

6 Sequential commands are desired on this key 
(e.g. , Read Next) 

7 Duplicates are allowed on this key 

<09 The key length, in bytes (characters), of the 

primary key. 

<0A The starting byte number for the position of the key 

within the key indexed file data record. The prior 
three items (flags, character count of key, and key 
offset) are repeated for each secondary key. 

<40 * 

Figure 4-20 shows a dump of the directory file .JB.DIR. The directory 
contains a sequential file ( .JB.DIR. SEQ) , an image file ( .JB.DIR. IMAG , 
a program file" ( .JB.DIR. PROG) , and a key indexed file ( . JF.DIR.KEY) . 
The directory also contains an alias for the key indexed file. ihe 
directory was created to have 11 entries, in addition to record which 
is the directory overhead record. 

4.3.4-3 Image Files. 

Image files are nonexpandable, unblocked relative record files that 
contain memory images of programs. They are not organized in any 
format; that is, each sector of the image file, starting with the first 
sector, is completely filled with data. There are no overhead records 
or words. Image files are designed so that a program image can be read 
into memory in a single disk access. 
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FILE:. JB. DIR RECORD 


: 000000 


OOOO OOOB 0004 0005 


OOOO 4449 


0010 0002 4A42 2020 


2020 2020 


SAME 




0084 0000 




FILE:. JB. DIR RECORD 


: 000001 


0086 0002 ooo : 


5345 5 1 20 


0094 0000 1A00 0120 


0028 0001 


00A4 0000 0000 0000 


OOOO OOOO 


00B4. OOOQ 0000 0000 


OOOO 07B9 


00C4 01D4 7E49 0103 


OOOO OOOO 


SAME 




010A 0000 




FILE:. JB. DIR RECORD: 


: 000002 


010C 0000 0001 


494D 4147 


01 1A 0000 C420 0120 


0120 0004 


01 2 A 0000 0000 0000 


OOOO OOOO 


01 3A 0000 0000 0000 


OOOO 07B9 


014A 01D4 7E3B 0103 


OOOO OOOO 


SAME 




0190 0000 




FILE: . JB. DIR RECORD: 


: 000003 


0192 0000 0000 


OOOO OOOO 


SAME 




0216. 0000 




FILE:. JB. DIR RECORD: 


: 000004 


0218 OOOO 0000 


OOOO OOOO 


SAME 




029C OOOO 




FILE:. JB. DIR RECORD: 


: 000005 


029E OOOO OOOO 


OOOO OOOO 


SAME 




0322 OOOO 




FILES. JB. DIR RECORD: 


: 000006 


0324 OOOO OOOO 


OOOO OOOO 


SAME 




03A8 OOOO 




FILE:. JB. DIR RECORD: 


000007 


03AA 0001 0007 


5052 4F47 


03B8 OOOO 8C20 0120 


0120 00 ID 


03CS OOOO OOOO 0O4A 


OOOO 004A 


03D8 OOOO OOOO OOOO 


OOOO 07 B9 


03ES 01D4 7E77 0103 


OOOO OOOO 


SAME 




042E OOOO 




FILE:. JB. DIR RECORD: 


000003 


0430 OOOO OOOO 


OOOO OOOO 


SAME 




04B4 OOOO 




FILE:. JB. DIR RECORD: 


000009 


04B6 0001 0009 


4B45 5946 


04C4 OOOO 1E13 OOOO 


OOOO OOOO 


04D4 OOOO OOOA OOOO 


OOOO OOOO 


SAME 




053A OOOO 




FILE:. JB. DIR RECORD: 


OOOOOA 


053C 0001 OOOA 


4B45 5920 


054A OOOO 1E03 0120 


0050 00 IB 


055A 0009 OOOO OOOO 


OOOO OOOO 


056A 0027 0029 0025 


OOOB 0739 


057A 01D4 7E1C 0103 


0009 OOOO 


SAME 




05C0 OOOO 




FILE:. JB. DIR RECORD: 


00000 B 


05C2 OOOO FPFD 


0064 0002 


05D0 0004 OOOO OOOn 


OOOO OOOO 


SAME 




0646 OOOO 




2278136 





5220 2020 2020 
OOOO OOOO OOOO 



2020 2020 OOOO 
016E 0001 OOOO 
OOOO OOOO OOOO 
01D4 7E49 07B9 
OOOO OOOO OOOO 



2020 2020 OOOO 
1065 0001 OOOO 
OOOO OOOO OOOO 
01D4 7E3B 07B9 
OOOO OOOO OOOO 



OOOO OOOO OOOO 



OOOO OOOO OOOO 



OOOO OOOO OOOO 



OOOO OOOO OOOO 



2020 2020 OOOO 
24A9 0001 OOOO 
OOOO OOOO OOOO 
01D4 7E73 07B9 
OOOO OOOO OOOO 



OOOO OOOO OOOO 



494C 4520 OOOO 
OOOO OOOO OOOO 
OOOO OOOO OOOO 



2020 2020 OOOO 
24SE 0002 OOOO 
OOOO OOOO 004E 
01 D4 7E1D 07B'? 
OOOO OOOO OOOO 



i'.'104 OOOO 0005 
OOOO OOOO 00<'""> 



DI R 



JB 



IM AG 



... PR 00 

. . * 

. . J . . .J 

. . . KE YF IL E 

. . . KE Y 

.P . . J 

N 

) . */. 



Figure 4-20 Directory Pile Dump 
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SECTION 5 
SYSTEM FILES 



5 • 1 GENERAL 

This section describes the structure and purpose of various files 
used by DX10. These special files are: 

* System program file 

* System overlay file 

* Crash file 

* Roll file 

The files used by the System Command Interpreter are discussed in the 
section on SCI. 



5-2 SYSTEM PROGRAM PILE 

The system program file has the same structure as g general 
program file, as described in the section on disk data structures. It 
is called the system program file because it contains all of the disk 
resident system tasks and their overlays, as -fell as ^pny utility 
programs. " 

Queue-serving system tasks on the system program file include: 

* SLMPOT - System log message formatting and output task 

* TMSSBD - Scheduled Bid Task SVC processor 

* TMDGN - Termination task 

* SVCKIL - Kill TASK SVC processor 

* PF$LIN - Install Task, Procedure, and Overlay SVC processor 

* PF$L0E - Delete Task, Procedure, and Overlay SVC processor 

* PUTIL - Pile Utility SVC processor 

* PFSLMN - Map Name to ID SVC processor 
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* PF$LAS - Assign Space on Program Pile SVC processor 

* INSTAL - Install, Unload, Initialize Volume SVC processor 

5-3 SYSTEM OVERLAY PILE 

The system overlay file is an unblocked relative record file used 
to contain system overlays. Each overlay is placed in the record that 
corresponds to the overlay number, and is in memory image format. Each 
record is 800 bytes. 

When a system overlay is requested, the record that corresponds to the 
required overlay number is read directly into one of the system overlay 
areas by the system overlay loader, thus incurring very little 
overhead. 

Table 5-1 shows what overlays are contained on the system overlay file. 

Table 5-1 System Overlay Numbers 

Overlay Number/ 

Pile Record Overlay 

1 Key indexed file B-Tree split routine 

2 Key indexed file record insert routine 

3 More key indexed file record insert 

4 Key index file open and close routine 

5 Sequential placement B-Tree Split routine 

6 Sequential placement record insert routine 

7 More sequential placement record insert 

8 KIP record delete overlay 

9 KIP delete B-Tree entry 

A Sequential placement record delete overlay 

B Sequential placement record delete overlay 

C Sequential placement delete B-Tree entry 

D-P Disk manager overlays 

10-13 Pile manager overlays 

14 Disk manager overlay 

20 Bidder task error recovery routine 



5.4 CRASH PILE 

The system crash file, . SSCRASH, is an image file created large 
enough to contain a dump of all memory. When a system crash occurs, 
the routine SCRASH displays the crash code on the front panel lights 
and idles the CPU. If a dump is taken, SCRASH writes all of memory to 
the file . SSCRASH. This file may later be used as input by the crash 
analysis program, ANALYZ . 
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5«5 ROLL PILE 

The roll file is an expandable image file that is used to contain 
rolled-out task and procedure images. It is created by the CSP (Create 
system Piles) command. 

There is no single directory of roll file entries. Instead, a linked 

l 1S l %L J™1 and PSBs of rolled tasks and Procedures is maintained. 
-j--- -~~ u,m x^^ ^wnuaiue out? starting record number and number of roll 

;;i? AT rec01,ds L us ^ d ^ that segment. When the roll allocation routine," 
TMRDAL, searches for a block of free roll file smce, it runs down the 
±ist until it finds a hole between segments, or smce between the last 
rolxed segment and the end of the file, large enough to fill the 
request for roll space from the task loader. The roll file may be 
extended, if necessary. 
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SECTION 6 
DATA STRUCTURES 



6 . 1 GENERAL 

Memory resident data structures within DX10 consist of many tables 

queues, and buffers. Most of the tables and buffers are dynamically 

allocated from the system table area. Most of the system 

anchored in the DX10 data base modules, DDATA 

following paragraphs describe the important data 

DX10. 



queues are 
and DXDAT2. The 
structures used by 



6 . 2 QUEUES 

The general structure of a DX10 queue is described in Section 1. The 
queues are singly linked, first-in, first-out lists of data structures 
to be processed. A queue is established by a queue anchor, which is 
usually a 10-byte block having a format as shown in Figure 6-1. 



Hex. 
Byte 



>00 
>02 
>04 
>06 
>08 



+ 



>0A * 



QUENEW — NEWEST ENTRY 



QUEOLD — OLDEST ENTRY 



QUETSB — TSB OP SERVER TASK 



■+- 



QUEFLG — ELAGS 
QUESTA — TASK STATE 



QUETID — SERVER ID 



i QUECNT — NO. OP ENTRIES | 
+ * 



Figure 6-1 Queue Anchor 
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Hex. 
Byte 

>00 



>02 



>04 



>06 



>07 

>08 

>09 
>0A 



Field 
Name 



QUENEW 

QUEOLD 
QUETSB 



QUEFLG 



QUETID 

QUESTA 
QUECNT 



Description 

The address of the newest (last) entry on the queue. 
Note that since this is only a one-word address, it 
is implied that the queued structures are mapped in 
with the queue anchor. 

The address of the oldest (first) entry on the 
queue. 

The address of the task status block of the queue 
serving task (see paragraph 6.7 on TSBs). This 
field is zero if no queue server exists for the 
queue, or if the queue server is not loaded into 
memory. 

Flags, which when set mean: 

Bit Meaning 

Priority ordered queue (TSBs with high 
priorities are at the front of the queue) . 

1 TSB queue (entries are TSBs). 

2-7 Reserved. 

The installed ID of the queue serving task (zero if 
no server) . Queue servers must be installed on the 
system program file. 

The task state that is to be assigned to all TSBs 
that are placed in this queue (=>FF if none). 

The number of entries currently in the queue. 



Most queue anchors are located in the module named DXDAT2. See Section 
7 for further information about DXDAT2. 



6.3 PHYSICAL DEVICE TABLE 

A Physical Device Table (PDT) is a data structure that represents a 

physical device to the operating system. In addition to containing 

information describing the device, the PDT is used as a workspace by 

the device service routine. Some of the uses of the PDT are discussed 

in Volume V of the DX1 reference manuals. A physical device table has 
the format shown in Figure 6-2. 
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Hex. 
Byte 

>00 

>02 

>06 

>08 

>0A 

>0C 

>0E 
>10 
>12 
>14 
>16 
>18 
>1A 

>1C 

>1E 

>20 

>22 

>24. 

>26 

>28 

>2A 

>2E 
>30 
>32 
>34 
>^6 



+■ 



+■ 



RO 

R1 

R2 

R3 

R4 

R5 

R6 

R7 

R8 

R9 

R10 

R1 1 

R12 

R1? 

R14 

R15 



+- 



+- 



+- 



+■ 



+■ 



+- 



+- 



+ 



+ 



+- 



+- 



+ 



+ 



+ 



+ 



+■ 



PDTLNK — FORWARD LINK TO NEXT PDT 



PDTMAP — POINTER TO DSR MAP PILE 



PDTRO — DSR SCRATCH 



PDTPRB — PRB ADDRESS 



PDTDSP — DEVICE STATUS FLAGS 



PDTDTE — DEVICE TYPE FLAGS 



PDTDIB — DEVICE INFO BLOCK ADDRESS 



PDTR5 

PDTR6 

PDTR^ 

PDTR8 

PDTR9 

PDTRIO 

PDTR1 1 



DSR SCRATCH 



PDTCRU — CRU OR TILINE BASE ADDRESS 



PDTR1? — SAVED WP REGISTER 



PDTR14 — SAVED PC REGISTER 



PDTR15 — SAVED ST REGISTER 



PDTS — PDT WORKSPACE ADDRESS 



PDTDSR — DSR ADDRESS 



-+• 



PDTERR — ERROR CODE j 
+- 



PDTFLG — FLAGS 



PDTNAM — DEVICE NAME 



PDTSL1 — SYSTEM LOG 1 



PDTSL2 — SYSTEM LOG 2 



PDTBUF — NOT USED 



PDTBLN — BUFFER LENGTH 



PDTINT — DSR INTERRUPT ADDRESS 



Figure 6-2 Physical Device Table (Part 1 of 2) 



+ 



+ 



+ 



+ 



+ 



+ 



+ 



-+ 



-+ 



■+ 



■+ 



■+ 
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>^8 

>42 

>44 
>46 
>48 



+ + 

! ! 

J PDTDVQ — DEVICE QUEUE ANCHOR , 

i ' 

i 

+ 



PDTM1 - 


- TIME 


OUT 


COUNT 


1 


PDTM2 - 


- TIME 


OUT 


COUNT 


2 


PDTSRB - 


- SAVED PRB ADDRESS 



+ + 

I T>iMTn«rt rn -ruir-n r\TTm n rsrr-KTm o I 



+ 



Figure 6-2 Physical Device Table (Part 2 of 2) 



Hex. Field 

Byte Name Description 



>00 PDTLNK Address of the next PDT and the PDT expansion block 

for this PDT. All the PDTs are linked in a single 
list that is located in the D$DATA module. 

Address of the DSR map file. 

This -word "begins the workspace to be used by the 
device service routine initial entry processor. 

Address of buffered I/O supervisor call block. 

Device status flags that are set by the system: 

Bit Meaning When Set 



>02 


PDTMAP 


>04 


PDTRO 


>06 


PDTPRB 


>08 


PDTDSF 



Device is opened; i.e., LUNOs are assigned to 
the device. 

1 Device is busy. 

2 Kill I/O at this device is in progress. 

3 Task doing I/O at this device is being killed. 

4 Make this device available (unassigned) at the 
end of this I/O operation. 

5 Signals the task scheduler to reenter the DSR. 
This flag can be used by a DSR to wait for a 
device, by setting the flag and then returning 
to the system. 

6 End-of-record processing needs to be done for 
this device; i.e., data transfer is complete. 

7 ;= ASCII. 1 s JISCII. 
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>09 



>0A 



PDTDTF 



>0C 



PDTDIB 



>0E 



>1C 



PDTR5 
thru 
PDTR1 1 

PDTCRU 



Interrupt mask to be used "by the DSR. This field is 
the interrupt level assigned to the device minus 
one, and is set at system generation time. 

Device type flags that are all set at system 
generation time except for the system disk flag" that 
is set "by the system loader. 



Bit 


1 
2 

4 
5 



Meaning When Set 

Pile oriented device (if the flag is zero, the 
device is record oriented"). 

Device uses the TILINE data bus. 

The time-out logic should be enabled for this 
device. 

Device may only be used by privileged tasks. 

This is a terminal (keyboard device) with a 
keyboard status block attached to the PDT. 

This is a communications device. 

6 This is the system disk. 

7 A PDT extension exists. 
8-11 Not used. 

12-15 Device type code, as follows: 

— Dummy 

1 — Teleprinter 

2 — Line Printer 

3 — Cassette 

4- — Card Reader 

5 — Video Display Terminal 

6 — Disk and Diskette 

7 — Communications 

8 — Magnetic Tape and AMPL 
E — AMPL Emulator 

E — AMPL Trace Module 

Pointer to the word after the PDT itself. This may 
be the address of the keyboard status block ^KSB), 
disk PDT extension (DPD), tape PDT extension (TPD^ 
or line printer PDT extension (LPD) depending upon 
the type of device. 

Scratch registers to be used by the DSR. 



'he CRU or TILINE address of the device. 
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>1E 



>24 



PDTR1 ^ 
PDTR1 4 
PDTR1 5 

PDT$ 



>26 


PDTDSR 


>28 


PDTERR 


>29 


PDTPLCr 



>2A 
>2E 

>32 
>34 

>36 
>38 

>42 
>44 



PDTNAM 

PDTSL1 , 
PDTSL2 



PDTBUE 
PDTBLN 

PDTINT 
PDTDVQ 

PDTM1 
PDTM2 



These three words contain the saved context (WP, PC 
ST) to which the DSR returns control via a RTWP. 

Pointer to the "beginning of the PDT workspace; i.e., 
byte 4 of the PDT J 

A pointer to the beginning of the DSR. 

Error code returned by the DSR. 

Device flags as follows: 

Bit Meaning When Set 

8 Use PRB in log message. 

9 Receive mode for JISCII. 

10 Transmit mode for JISCII. 

11-12 Device state: online = 00, offline = 01, 
diagnostic = 10. 

14 Operation failed bit. 

The 4-character device name. 

Por CRU devices, these words contain the controller 
image after an error. For TILINE devices, these 
words contain a pointer to the controller image 
after an error. 

Not used. 

Maximum length of a data buffer which may be 
transferred by the device in an I/O operation ('e.g., 
80 for a card reader). This is only necessary for 
CRU devices. 

The interrupt entry address of the DSR and reenter- 
me-address. 

The anchor for the queue of I/O requests for this 
device. The anchor has the same format as the queue 
anchor described in paragraph 6.2. 

The number of system time units in the time-out 
count for the device. 

The number of time units remaining in the time-out 
count before the system assumes that a device error 
has occurred. When the DSR starts an I/O operation, 
it should move the time-out count in bytes >42->43 
to this word. This word is then used by the 
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scheduler as the time-out counter. Each time a 
system time unit has elapsed, the scheduler 
decrements the time-out count and sets the time-out 
enable flag (bytes >OA->OB) . If the counter goes to 
zero before a device interrupt occurs (and the DSR 
resets the counter or the flag), the system assumes 
that a device error has occurred and reports it. 



>46 



>48 



PDTSRB The address of the 
plus two (offset 



H^Smea Dupcivisur Can diock, 
to PRB; see the DX10 Operating 
System Systems Programming Guide) . " 



All PDTs must be defined during system generation. The PD^s arp 
concatenated and inserted into the D$DATA module by GEN990. 

Under DX10, PDTs for disks and terminals each have an extension that is 
used mainly by the interrupt processing routine of the DSR. The 
following paragraphs describe those extensions. 

6.%1 PDT EXPANSION BLOCK. 

Every PDT has a 10-byte expansion block. The end of this block is 

?° 1 ? t ^m /° b T the link t0 the next PDT r PDTLNK). In the case of the 
last PDT (DS01) where the link is zero, PDTLST in ROOT points to the 
expansion block. The format of the PDT expansion block is shown in 
.figure o—p. 



Hex. 
Byte 

->0A 

->08 

->06 

->04 

->02 



+■ 



RESERVED — SET TO ZERO 



PDTRED — READ OPERATIONS COUNT 



PDTWRT — WRITE OPERATIONS COUNT 
PDTOTH — OTHER OPERATIONS COUNT 



+ 



+ 



PDTRTY — RETRIES COUNT j PDTLUN — LIJNOS COUNT 



-+ 



•+ 



-+- 



Figure 6-1 Physical Device Table Expansion Block 
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Hex. 
Byte 

->0A 
->08 

->06 

->04 

->02 
->01 



Field 
Name 



PDTRED 

PDTWRT 

PDTOTH 

PDTRTY 
PDTLUN 



Description 

Reserved. Initialized to zero. 

The number of read operations that have "been 
performed. 

The number of write operations that have been 
performed. 

The number of other operations that have been 
performed. 

The number of retries. 

The number of LUNOs assigned. 



6.3.2 DISK PDT EXTENSION (DPD) . 

The extension that is appended to disk PD m s is 96 bytes long. The 
format is shown in Figure 6-4. 



Hex. 
Byte 



>48 
>4A 
>4C 
>4E 
>50 
>52 
>54 
>56 
>58 
>5A 
>5C 
>5E 



* + 

DPDPRB — PILE MGMT PRB | 

+ 



+ 



+ - 



+- 



+ ■ 



+- 



DPDERR — ERROR CODE 

DPDPOP — OP CODE ! DPDLUN — LUNO 

+ 

DPDSFG — SYSTEM FLAGS \ DPDUFG — USER FLAGS 

— + 

DPDBUF — BUFFER ADDRESS 

DPDRCL — RECORD LENGTH 

DPDCCT — CHARACTER COUNT 

DPDADU — ADU NUMBER 

DPDSCT — SECTOR OFFSET 



+- 



■+ 

■+ 



+ +-FILE 
MGMT 
I/O 
SVC 



■+ 



+■ 



DPDWTK — WORDS /TRACK 

+ 

DPDSTK -- SECTORS/TRACK j DPDOHD -- OVERHEAD /RECORD 

+ 

DPDCYL ~ HEADS AND CYLINDERS 



+- 



+• 



DPDSRD — SECTORS/RECORD ! DPDRTK -- RECORDS/TRACK 
Figure 6-4 DisTs: PDT Extension (Part 1 of 2^ 



-+ 



+ 



+-+ 
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>60 
>62 

>78 
>7A 

>82 
>84 
>86 
>88 
>8A 
>8C 
>8E 
>90 

>98 
>A8 



I 

+ 



DPDWRD — WORDS/RECORDS 



DPDTIL — TILINE IMAGE 
(DPDILF — INTERLEAVING FACTOR) 



DPDIBF — INITIALIZATION BUFFER 



DPDFCB — POINTER TO VCATALOG FCB 



DPDVNM — VOLUME NAME 



DPDFMT — FILE MANAGER TSB ADDRESS 



DPDFMW — FILE MANAGER TASK AREA ADDRESS 
DPDPBM — DISK MANAGER BUFFER ADDRESS 
DPDMAD — MAXIMUM NO. OF ADUs ON DISK 

DPDSAD — SECTORS/ADU 
DPDDRS — DEFAULT PHYSICAL RECORD SIZE 
DPDECT — ERROR COUNT 



DPDTFL — TEMPORARY FILE NAME SEED 



DPDSLG — TILINE IMAGE FOR SYSTEM LOG 



DPDFLG — FLAGS WORD 



Hex. 
Byte 



Figure 6-4 Disk PDT Extension (Part 2 of 2) 



Field 
Name 



Description 



>48 



>58 



DPDPRB These 16 bytes are a copy of the file I/O supervisor 
call block. 

DPDWTK Number of words per track on the disk. 
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>5A 



DPDSTK 



Number of sectors per track. 



>5B 



>5C 



DPDOVH 



DPDCYL 



>5E 


DPDSRD 


>5F 


DPDRTK 


>60 


DPDWRD 


>62 


DPDTIL 


>62 


DPDILF 


>72 


DPDIBF 


>78 


DPDFCB 


>7A 


DPDVNM 


>82 


DPDFMT 



>84 


DPDFMW 


>86 


DPDPBM 


>88 


DPDMAD 


>8A 


DPDSAD 


>8C 


DPDDRS 


>8E 


DPDECT 



Number of overhead bytes per physical record (equal 
one sector) . 

Number of heads and cylinders as follows: 

Bit Meaning 



0-4 Number of heads on the disk. 
5-15 Number of cylinders. 

Number of sectors per physical record (=1) . 

Number of physical records per track. 

Number of words per record. 

An image of the eight TILINE controller registers 
for the disk. 

Interleaving factor, integer number, saves first 
word of TILINE controller registers image. 

The buffer used to hold information returned by the 
Store Registers direct disk I/O call. 

A pointer to the file control block for the disk 
volume directory (see paragraph 6.4). 

The 8-character name of the volume that is currently 
installed on the disk unit. 

The address of the task status block (see paragraph 
6.7) for the file management task for this disk 
controller. 

The address of the file management task work area 
(see the section on D$DATA) . 

The address of the disk manager buffer for this 
disk. 

The maximum number of ADUs on this disk. 

The number of sectors per ADU. 

The default physical record size for this disk, as 
defined to GEN990. 

A count of the number of controller errors returned. 
This count is reinitialized when the system is 
booted. 
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>90 DPDTFL The temporary file name last used. 
>98 DPDSLG A copy of the TILINE image used by the system log. 
>A8 DPDFLG Flags as follows: 

Bit Meaning 

DPFRTY — No retry desired. 

1 DPFRAW — Disk read after write. 

2 DPFBRW — Bit map read after write. 

6.3.3 TELEPRINTER DEVICE PDT EXTENSION (DIB). 

The Device Information Block (DIB) is a data structure appended to the 
PDT that contains information about the current status of the device as 
well as information about how it was configured at system generation 
time. Figure 6-5 shows the format of the TPD extension. 

Hex. 

Byte 

* , 

———————— ______ _ ____.|._ _____ ______ _____ _______ — _____* 

>00 I ACU CRU ADDRESS I 

+— „„. + j 

>02 | ISR TYPE (COMM-1, TTY-5) | 

"• + 4. 

>03 | LINE CONTROL TYPE (ALWAYS 0) | 

+ . _j. 

>04 | READ ASCII TIMEOUT I 

+ _ 1 

>06 | WRITE TIMEOUT I 

+ 1 

>08 | READ DIRECT TIMEOUT 1 | 

>:L I READ DIRECT TIMEOUT 2 I 

+ J 

>1 2 I SYSGEN ACCESS FLAGS I 

t + + 

>13 | STATE FLAGS I 

+ + 1 

>14 | LINE FLAGS I 

+____ + | 

>15 I TEMPORARY ACCESS FLAGS I 

+ + •_ 

>16 | SPEED (ENCODED) I 

J i 

>!' I END OF RECORD CHARACTER I 

+ J 

>18 I END OF FILE CHARACTER I 

+ 1 

>19 I LINE TURN AROUND CHARACTER I 

+ 1 

Figure 6-5 Teleprinter Device PDT Extension (Part 1 of 2) 
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+- 



>20 



>21 



>22 



>24 
>26 



>28 



>29 
>30 
>32 
>33 
>34 
>36 



>^8 



>40 



Hex. 
Byte 

>00 
>02 

>03 
>04 
>06 
>08 
>10 
>12 
>13 



+ 



+ 



+ 



+- 



+■ 



+■ 



+■ 



+■ 



+- 



+■ 



PARITY ERROR SUBSTITUTE 



CR DELAY INTERVAL 



PARITY CHECK ROUTINE 



PARITY SET ROUTINE 



MAXIMUM CHARACTERS BUPEERED IN FIFO 



TERMINAL TYPE 



LAST CHARACTER RECEIVED 



SAVED EXTENDED FLAGS 



SAVED ERROR CODE PROM ISR 



-+ 
•+ 
-+ 
-+ 
-+ 
-+ 
-+ 
-+ 
-+ 
-+ 



SPEED 



ISR VECTOR TABLE POINTER 



TIMEOUT 
+ 



NUMBER OP PARITY ERRORS 



NUMBER OP LOST CHARACTERS 

+ 



+ 



+ 



+ 



•+ 



Figure 6-5 Teleprinter Device Extension to PDT fPage 2 of 2) 
Description 



The CRU address of the ACU. 

The Interrupt service routine type, which is either 
communications (1) or teletype mode (*) 

The line control type, which is always 0. 

The Read ASCII timeout. 

The Write timeout. 

The Read Direct timeout 1 . 

The Read Direct timeout 2. 

The sysgen access flags. 

The state flags as follows: 
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Bit Meaning 

Online 

1 Connect in progress 

2 Open 

3 DLE received 

4 Half-duplex line belongs to remote 

terminal 

5 Resend flag 
6- 7 Unused 

>1 4 Line flags as follows: 

Bit Meaning 

Half-duplex modem 

1 Switched line 

2 Refuse call 

3 Auto-disconnect enable 

4 DLE/EOT for disconnect sequence 

5 SGP ready/busy monitor 

6 Pile transfer exclusive access 
^ Half-duplex LTA enable 



>20 
>21 
>22 



7 



15 The temporary access flags as follows: 

Bit Meaning 

No echo 

1 Unused 

2 Transmit parity enabled 
3-4 Transmit parity type 

00 = Even 

01 r-, Odd 

10 = Mark 

1 1 = Space 

5 Receive parity enabled 

&- n Receive parity type 

>16 The speed f encoded). 

>1 ? The end of record character. 

>18 The end of file character. 

>1 9 The line turnaround character. 

The parity error substitute character. 

The carriage return delay interval. 

The parity check routine pointer. 

>24 The parity set routine pointer. 
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>26 The maximum characters buffered in FIFO. 

>28 The terminal type. 

>29 The last character received. 

>30 The saved extended flags. 

>32 The saved error code from interrupt service 

routine. 

>33 The sysgened speed. 

>34 The interrupt vector table pointer. 

>36 The sysgened timeoiit. 

>38 The number of parity errors. 

>40 The number of lost characters. 

6.3.4 KEYBOARD STATUS BLOCK (KSB) . 

Each keyboard type device supported by DX10 has a KSB appended to the 
PDT for the device. The KSB is generally used by the keyboard 
interrupt decoder of the device service routine. Special keyboard 
devices that are supported by user-written DSRs need not have a KSB 
unless the System Command Interpreter (SCI) is to be bid at the 
terminal, in which case the KSB must be present. Figure 6-6 shows the 
format of a KSB. 
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Hex. 

Byte 

*. 



>0 ° R i KSBLDT — STATION LDT ADDRESS 

+ 

>02 RJ > ! KSBQOC — QUEUE LENGTH 

+ 

>Q 4 R2 ! KSBQIP — QUEUE INPUT POINTER 

+ 

>06 R ^ i KSBOOP — QUEUE OUTPUT POINTER 

+ 

>08 R 4 ! KSBQEP — QUEUE END POINTER 

+ 

>OA R5 ! RESERVED 



+■ 



+- 



+ 



+ 



+ 



+ 



+ + 



>OC R6 ! KSBPL — KSB FLAG } KSBSN — STATION NUMBER 
+ + 

>0E R7 ! KSBR7 — SCRATCH 



— + 



>10 R8 | KSBTSB — TSB ADDRESS/VALIDATION ^ABLE ADDRESS 

+ "_ 

>12 R9 J 

>1 4 R10| KSBRQ — SCRATCH 

>16 R11j 



+ 



+ 



>1S R12! KSBCRU — CRU BASE 

+ 

>1A R13! KSBR1*> — SAVED WP 

>1C R14! KSBRU — SAVED PC 

>1E R15i KSBR15 — SAVED ST 

>20 
>22 
>24 
>26 
>28 
>2A 
>2C 



Eigure 6-6 Keyboard Status Block 



1 

1 




KSBLDO — PDT ADDRESS 


1 

1 


KSBLD2 


-- LUNO ! KSBLDO — START I/O COUNT 


1 

1 




KSBLD4 — LDT ELAGS 


1 




KSBLD6 — LDT LINK 


1 

1 




KSBLDR — TSB ADDRESS 


1 
1 




KSBLCK — LOCK COUNT 



-+ 



+ 



+ 
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Field 


Byte 


Name 


>00 


KSBLDT 


>02 


KSBQOC 


>04 


KSBQIP 


>06 


KSBQOP 



>08 

>OA 
>OC 



>OD 
>OE 
>10 

>12 



KSBQEP 

RESERVED 
KSBPL 



KSBSN 
KSBR7 
KSBTSB 



KSBR9, 
KSBR10, 
KSBR1 1 



Description 



The offset into the KSB of the logical device table 
(LDT) anchor for station ( terminal) local LUNOs . 

The number of characters currently in the input 
character queue. 

A pointer to the next byte of the character queue 
that is available to receive an input character. 

A pointer to the oldest character in the input 
character queue, i.e., the next character to be 
picked up by the DSR. 

A pointer to the word after the character queue. 
That word contains the length of the queue. 



Flags as follows: 

Bit Meaning When Set 

Character mode (no mapping). 

1 Enable the command interpreter bid logic. 

2 Keyboard is in record mode (always set). 

3 Bid the command interpreter. 

4 The command interpreter is active. 

5 Halt I/O. 

6 Abort I/O. 
Station (terminal) ID. 

Scratch register for use by the DSR. 

The address of the TSB of the task currently using 
the terminal if the terminal is in character mode. 
If a validation table is being used, this field 
contains the validation table address. 

Scratch registers for use by the DSR. 
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Hex. 


Field 


Byte 


Name 


>18 


KSBCRU 


>1A 


KSBR1 3 



>20 



>2A 



KSBLDO 



KSBLCK 



Description 

The CRU address of the terminal. For VDTs, this 
address is >10 more than in the PDT. 

The saved context fWP, PC, ST) to which the DSR 
keyboard interrupt handling routine returns control 

-tr-i o q "DrnWD ■; ~ «+• „,, ~ -I- 4 

■'J-a rX iixjyx XIlOUl UU U X UI1 • 

These 10 bytes form a logical device table (see 
paragraph 6.5 on LDTs) that serves as an anchor for 
the terminal local LDT list, as described in Section 
1 . Flag bit in byte >24 is set to mark this LDT 
as an anchor. This LDT assigns terminal local LUNO 
to the terminal itself. 

The lock out count, which is a count of the) the 
number of Read With Event Characters SVCs issued for 
this terminal. 



>2C 



6.3.4.1 Video Display Terminal Extension (VDT). 

The VDT is an extension to the KSB used by the Q1 1 and 91^ terminals. 
The offsets are expressed from the beginning of the Physical Device 
Table (PDT) to which the KSB has been appended. Figure 6-^ shows the 
format of the VDT extension. 

Hex. 
Byte 



>2C 
>2E 
>30 
>32 

>34 
>36 
>?8 
>3A 
>3C 

>40 



+- 
1 

i 

+■ 
1 

1 

+- 
1 

1 

+- 



VDTEUF — EXTENDED USER FLAGS 

+ 

VDTFIL — FILL CHAR | VDTEVT — EVENT CHAR 

+ 

VDTPOS — CURRENT CURSOR POSITION 

VDTDEF — START OF FIELD 

VDTSC1 — SCRATCH 



VD 


TSC2 


— SCRATCH 


VD 


TSC5 


— SCRATCH 


VDT, 


JIN - 


— BIT MASK 


UNUSED 



Figure G- n Video Display Terminal Extension to KSB 
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Hex. 
Byte 



Field 
Name 



Description 



>2C 

>2E 

>2F 

>30 
>32 
>34 
>36 
>38 
>3A 



VDTEUF 

VDTFIL 

VDTEVT 

VDTPOS 
VDTDEF 
VDTSC1 
VDTSC2 
VDTSC3 
VDTJIN 



>3C->3F - 
>40 * 



The extended user flags to be used during the 
current operation. 

The fill character to be used during the current 
operation. 

The event character to be returned to the user 
call block. 

The current position of the cursor. 

The beginning of the field. 

Scratch field for use by the extension. 

Scratch field for use by the extension. 

Scratch field for use by the extension. 

A mask that is used to set bit of a character 
to the appropriate value. 

Not used. 



6.3.4.1A Electronic Video Terminal Extension (VDT940) . 



The VDT940 is an extension to the KSB used by the 940 terminals. 
The offsets are expressed from the beginning of the Physical Device 
Table (PD' 1 ') to which the KSB has been appended. Figure 6-7A shows 
the format of the VDT940 extension. 



NOTE 

The meaning and position of the flags are for 
TI internal use only and may be moved, changed 
or deleted at any time. 



The VDT940 has the following format: 
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Hex. 
Byte 
+ + 

>2C | VDTEUF - EXTENDED USER FLAGS | 

+ + _ + 

>2E | VDTFIL - FILL CHARACTER | VDTEVT - EVENT CHARACTER | 
+ + + 

>30 | VDTPOS - CURSOR POSITION | 

+ . + 

>32 | VDTDEF - FIELD DEFINITION I 



>34 | VDTRED - READ DIRECT WORD 

+ 

>36 | VDTSC1 - FLAG WORD 1 

+ . 

>38 I VDTSC2 - FLAG WORD 2 



>3A | VDTSC3 - TEMP LINK SAVE LOCATION 

+ . __ + 

>3C I RESERVED I GENSPD - TERMINAL SPEED 



>3E | RESERVED | 

+ + + 

>40 | VDTATT - ATTRIBUTE SENT | VDTATB - ATTRIBUTE RECEIVE | 

>42 J VDTSC4 - TEMP LINK SAVE LOCATION | 

+ _ + 

>44 | VDTCNT - COUNT FOR VDTRED | 

+ + 

>46 J VDTPTR - POINTER TO PRINTER PDT I 



>48 | VDTSC5 - LINK REGISTER FOR CHANGING CHARACTER SETS | 
+ ___ . + 

>4A | VDTMFL - FLAG WORD FOR MODE FLAGS | 

+ _ + 

>4C | VDTEDL - FLAG WORD FOR EVENT KEY FLAGS | 

+ + 

>4E | VDTSIZ - NO. OF CHAR SCREEN MEMORY | 

+ + 

>50 | VDTFIS - SAVE RO FOR FIFO | 

+ + 

>52 | VDTSC6 - TEMPORARY STORAGE | 

+ + 

Figure 6-7A Electronic Video Terminal Extension to KSB (Part 1 of 2) 
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+ + 

>54 | FIFOCT - FIFO COUNT | 

+ + 

>56 I FIFO IP - FIFO INPUT POINTER | 

+ + 

>58 I FIFOOP - FIFO OUTPUT POINTER | 

+ + 

>5A | FIFOEP - FIFO END POINTER | 

+ + 

>5C I FIFOBP - BEGINNING OF FIFO | 

+ + 

+ + 

I FIFOPT - FIFO LENGTH | 

+ — . + 

Figure 6-7A Electronic Video Terminal Extension to KSB (Part 2 of 2) 



Hex. 


Field 


Byte 


Name 


>2C 


VDTEUF 


>2E 


VDTFIL 


>2F 


VDTEVT 


>30 


VDTPOS 


>32 


VDTDEF 


>34 


VDTRED 



Description 

The extended user flags to be used during 
current operation. 

The fill character to be used during the current 
operation. 

The event character to be returned to the user 
block. 

The current position of the cursor. 

The beginning of the field. 

The buffer or address of the buffer for the read 
to address based on the flag in VDTSC1 (see byte 
>36) . 
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Hex. 
Byte 



Field 
Name 



Description 



>36 



VDTSC1 Flag word 1 as follows: 
Bit Meaning 



3 

4 

5 

6 

7 

8 

9 

10 

11 

13 

14 
15 



Found beginning of Read Information 

Next start of header was requested by the 

DSR 

Read information goes into address in 

VDTRED (set to 1); otherwise stored in 

VDTRED 

Found first ESC in response 

Found a right parenthesis in string 

A second ESC was found in string 

An aid character* was found 

A change character set was found 

An attribute character was found 

The cursor position was found 

The requested read was finished 

Indicates terminal is in insert mode 

Indicates terminal is connected to 

computer 

Indicates modem phone has rung 

Instructs DSR to set re-enter me flag 



>38 



VDTSC2 Flag word 2 as follows: 

Bit Meaning 

Timed out device 

1 Time out for response 

2 Printer has control of line 

3 Printer wants control of line 

4 EVT has control of channel 

5 EVT wants control of channel 

6 Extended character is in SCI 

7 Extended character is in SC2 

8 Alternate character set is in terminal 

9 Alternate character set is on input 

10 Alternate character set is on read 
address 

11 Graphics set is in terminal 

12 Graphics set is on input 



to 



Aid characters are the SEND key, and the 24 function keys. 
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Hex. 
Byte 



Field 
Name 



Description 



>38 



VDTSC2 



>3A 
>3C 
>3D 



>41 
>42 
>44 



Flag word 2 as follows: 
Bit Meaning 



VDTSC3 

Reserved 

GENSPD 



13 Graphics is set on read to address 

14 Terminal busy flag 

15 A mode 3 table check is in progress 

Link register save location 



Terminal definition as follows: 
Bit Meaning 








Set if switched 




3-7 


Speed of 


terminal: 






Setting 




Speed 






11110 




110 baud 






10101 




300 baud 






10001 




600 baud 






11111 




1200 baud 






11011 




2400 baud 






10111 




4800 baud 






10011 




9600 baud 


>3E 


Reserved 






>40 


VDTATT Attribute sent 


to 


terminal a 




Bit 


Meaning 







VDTATB 
VDTSC4 
VDTCNT 



2 Double wide characters 

3 Nondi splay 

4 Blink display 

5 Underline display character 

6 Reverse image display character 

7 High intensity display character 

Attribute received from terminal bit definition 
the same as VDTATT 

Link register save location for outputting 
characters 

Counter for VDTRED 
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Hex. 


Field 


Byte 


Name 


>46 


VDTPTR 


>48 


VDTSC5 


>4A 


VDTMFL 



>4C 



VDTEDL 



Description 

Pointer to PDT of attached printer, if present 
Link register for changing character sets 

Bit Meaning 





1* 

2* 

3 
4 
5** 

6** 
7** 

8 
9 



ESC right 



Pass through flag 

Terminate on receipt of ETX 

Terminate on receipt of 

parenthesis 

Extended event characters 

Extended display characters 

Allow ESC and SOH through write ASCII 

Do not set attributes 

132-column mode 3 flag 

Modified data to caller 

Extended character validation 



10-15 Reserved 

Flag word for event key flags as follows: 

Bit** Meaning 





1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 



Erase field 

Right field 

Cursor left out of Field 

Tab 

Reserved 

Skip 

Home 

Return 

Erase input 

Reserved 

Delete character 

Insert character 

Cursor right out of field 

Enter 

Left field 

Reserved 



*Flag applies only if bit of VDTMFL is on. 
**Flag applies only if bit 3 or bit 4 of VDTMFL is on. 
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Field 


Byte 


Name 


>4E 


VDTSIZ 


>50 


VDTFIS 


>52 


VDTSC6 


>54 


FIFOCT 


>56 


FIFOIP 


>58 


FIFOOP 


>5A 


FIFOEP 


>5C 


FIFOBP 



Description 

Number of characters of screen memory 

Save RO for FIFO 

Temporary storage 

FIFO count 

FIFO input pointer 

FIFO output pointer 

FIFO end pointer 

Beginning of FIFO 



FIFOPT FIFO length (beginning address of FIFO and 
length of FIFO set at system generation time) 



6.3.4.2 KSR Extension (KSR) . 

The KSR is an extension to the KSB used by keyboard-type devices 
such as the 733. The offsets are expressed from the beginning of 
the Physical Device Table (PDT) to which the KSB has been appended. 
Figure 6-8 shows the format of the KSR extension. 
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Hex. 
Byte 



>2C 

>2E 

>32 

>34 
>^6 

>3A 
>3C 
>3E 
>40 



+■ 
+- 
+- 
+- 
+- 
+- 
+- 
+- 

+- 

■*_ 
* 



KSRABT — ABORT ROUTINE ADDRESS 



KSRCRD — CARRIAGE RETURN DELAY COUNT 



■- INTER-CHARACTER D.HLAY COUNT 



KSRSSC — CASSETTE STATUS 



KSRACP — ACTIVE PDT ADDRESS 



KSRQP1 — FIRST QUEUED PDT ADDRESS 



KSRQP2 — SECOND QUEUED PDT ADDRESS 



KSRXUE — EXTENDED USER FLAGS 



-+- 



-+ 



■+ 



■+ 



-+ 



■+ 



■+ 



KSRFLG — GENERAL FLAGS | KSRSCH — SAVED CHARACTER 



KSRTMO — TIMEOUT COUNT 



Figure 6-R KSR Extension to KSB 



Hex. 


Field 


Byte 


Name 


>2C 


KSRABT 


>2E 


KSRCRD 


>30 


KSRICD 


>32 


KSRSSC 


>34 


KSRACP 


>36 


KSRQP1 


>38 


KSRQP2 


>3A 


KSRXUF 



Description 

The address of the abort routine. 

The carriage return delay count. 

The inter-character delay count. 

The status of the cassettes. 

The address of the active PDT for the 73^ 

The address of the first queued PDT. 

The address of the second queued PDT. 

Extended user flags. 
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>3C KSRFLG General flags as follows: 

Bit Meaning When Set 

Hang up condition. 

1 Time out switch. 

2 SCI is active during hang up. 

3 A data carrier drop was detected. 

4 Shift in/out for JISCII. 

5 Direct character input requested. 
>?D KSRSCH Character saved for JISCII output. 

>3E KSRTMO Timeout count for hang condition. 
>40 * 

6.^.4-3 820 Extension (T82). 

T82 is an extension of the KSB for the ^20 terminal. The offsets are 
expressed from the beginning of the Physical Device Table (PDTi to 
which the KSB has "been appended. Some fields must he compatible with 
the KSR because they are used outside of the Device Service Routine 
(DSR). Figure 6-9 shows the format of the 820 extension. 

Hex. 

Byte 

* * 

>2C ! T82PRB — SYSTEM FLAGS AND USER FLAGS ! 

+ 1 

>2F ' i 

~ T82EXT — EXTENDED PRB FLAGS ~ 

. ! 

1 

+ J 

>3C ! T82FLG — GENERAL FLAGS I 

+ + 

>3E J T82TM0 — TIMEOUT COUNT ! 

* * 

>40 * 

Figure 6-Q «20 Extension to KSB 
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Hex. 


Field 


Byte 


Name 


>2C 


T82PRB 


>2E 


T82EXT 


>3C 


T82FLG 



>3E 
>40 



T82TM0 



Description 

System and user flags to be used during the current 
operation. 

Flags from the extended Physical Record Block (PRB); 
yj xx nu o extended. 

General flags as follows: 

Bit Meaning When Set 

Hang up condition. 

1 Time out switch. 

2 SCI is active during hang up. 

3 A data carrier drop was detected. 

4 Shift in/out for JISCII. 

5 Direct character input requested, 
The timeout count. 



6.3.4.4 Character Queue. 

The character queue follows the KSB and KSB extension for terminal 
devices. Currently, the character queue starts at >64 from the 
"beginning of the KSB. However, all references to the queue should "be 
through the KSB pointers. The length of the queue is set at SYSGEN 
time. The word following the queue buffer is the length of the queue. 

6.3.5 LINE PRINTER EXTENSION (LPD) . 

The line printer extension to the PDT is used for both fast (22^0/2260) 
and slow (e.g., 810) line printers. Figure 6-10 shows the format. 
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Hex. 
Byte 



>00 
>02 
>04 
>06 
>08 
>0A 
>0C 

>B6 



Hex. 
Byte 

>00 



+ 



+- 



+- 



+- 



+- 



LPDDMF — PRINTER TYPE 

LPDCC — CHARACTER COUNT 

LPDOUT — NEXT OUTPUT CHARACTER ADDRESS 

LPDIN — NEXT INPUT BY^E 

LPDMXC — MAXIMUM CHARACTERS 

LPDENR — END RECORD FLAG- 



+- 



Eield 
Name 

LPDDMF 



>02 


LPDCC 


>04 


LPDOUT 


>06 


LPDIN 


>08 


LPDMXC 


>OA 


LPDENR 


>OC 


LPDBUE 


>B6 


* 



LPDBUE — CHARACTER BUFFER 
(1-70 BYTES) 



■+ 



•+ 



-+ 



+ 



+ 



Figure 6-10 Line Printer Extension 



Description 

Describes the type of line printer. A zero denotes 
a fast printer and a 2 denotes a slow printer. 

The number of characters currently in the buffer. 

A pointer to the next character to be output (unless 
LPDCC = 0) . 

A pointer to the next free byte in which a character 
can be stored f unless LPDCC = LPDMAX") . 

The maximum number of characters that may be stored 
in the buffer. 

Used as a flag to cause end record processing. 
The 1 ^O-byte character buffer. 
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6.3.6 TAPE EXTENSION (TPD). 

The tape extension to the PDT is similar to the disk extension. 
Currently, the disk and tape are the only TILINE devices. Certain 
fields in these extensions that are used outside the Device Service 
Routine (DSR) must "be in the same location. Therefore, the tapee 

a uc no xuu iiiuio u uo ulic: oaiDc oizjc cio one uioK cXXciiBiun* ngu.i'6 O— 1 1 

shows the format of the TPD. 

Hex. 
Byte 



>10 ! TPDSVS — DEVICE STATUS J 

+ . + 

>12 j TPDMAJ — MAJOR RETRIES COUN^ 1 ! 

+ + 

>1 4 j TPDMIN — MINOR RETRIES COUNT j 

>16 ! ! 

+ . + 

>18 ! j 

+ + 

>1A ! ! 

~ TPDTIL — CONTROLLER IMAGE 

! ! 

* * 



Figure 6-1 1 Tape Extension 



Hex. Field 

Byte Name Description 



>10 TPDSVS The device status for a device characteristics call. 

>12 TPDMAJ A count of the number of major retries left. 

>1 4 TPDMIN A count of the number of minor retries left. 

>1A TPDTIL The controller image created to start an operation. 
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6.^.7 FLOPPY DISKETTE EXTENSION (FPD). 

The floppy diskette PDT extension is used for CRU-type floppy diskettes 
(FD800). ' TILINE floppy diskettes (FD1HOO) use the normal disk PDT 
extension. Figure 6-12 shows the format of an EPD. 



Hex. 
Byte 



* . * 



>00 j FPDBAS -- NOT USED ! 

+. . _. . . + 

>02 ! FPDDNO -- DISK DRIVE NUMBER ! 

+ ■ + 

>04 ! FPDCMD — CONTROLLER COMMAND ! 

+ — _ + 

>06 j FPDLSC — CURRENT LOGICAL SECTOR NUMBER j 
+ + 

>08 ! FPDCTK — CURRENT TRACK POSITION ! 

+ + 

>OA ! FPDTRK — REQUESTED ^RACK POSITION j 

+_ + 

>OC ! FPDSCT — REQUESTED SECTOR POSITION ! 

+ + 

>OE ! FPDDBA — DATA BUFFER ADDRESS | 

+ — + 

>10 ! FPDDBL — DATA BUFFER LENGTH j 

4- . + 

>12 j FPDDBR — REMAINING CHARACTER COUNT ! 

+ _ + 

>14 ! FPDVCT — SAVED VECTOR ENTRY POINT ! 

+ + 

>16 ! FPDUSE — USE FLAG ! 

* * 

>18 * 

Figure 6-12 Floppy Diskette PDT Extension 
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Hex. 
Byte 


Field 
Name 

FPDBAS 
PPDDNO 


Description 


>00 
>'02 


Not used. 
The disk dr: 



>04 



>18 



PPDCMD 



>06 


PPDLSC 


>08 


FPDCTK 


>0A 


FPDTRK 


>0C 


PPDSCT 


>0E 


PPDDBA 


>10 


PPDDBL 


>12 


PPDDBR 


>14 


FPDVCT 


>16 


PPDUSE 



The disk drive number is contained in bits A. and R 
of this word. 

The command that is to be issued to the disk 
controller. 

The current logical sector number. 

The current track position. 

The requested track position. 

The requested sector position within the track. 

The data buffer address. 

The data buffer length. 

The remaining character count for multi-sector 
transfers. 

The saved vector entry point within the device 
service routine (DSR). 

Used as a flag to indicate that this PDT has control 
of the disk controller. 



6.4 PILE CONTROL BLOCK fPCB) 

Within DX10, files are represented by, or accessed through, -PilP 
control blocks. As described in Section 1, whenever a file is 
accessed, a tree structure of PCBs is built into memory. >his 
structure resembles the directory/file hierarchy on the disk. '"PCBs are 
built in the system table area by the Pile Utility Assign LUNO 
processor, and are basically a memory resident copy of the file 
descriptor record (FDR) of the file. Figure 6-1 ^ shows the format o^ a 
file control block. 
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Hex. 
Byte 



>00 
>02 
>04 

>0C 

>10 
>12 
>14 
>16 
>18 
>1A 
>1C 
>1E 
>20 
>22 
>24 
>26 
>28 

>2C 

>30 
>32 

>34 



+ 



+ 



+ 



+- 



+- 



+- 



+• 



+■ 



+■ 



+- 



+- 



+- 



+- 



+- 



+• 



+- 



+■ 



FCBLEN — LENGTH OP PCB 



FCBRNM — RECORD NUMBER OF FDR 



FCBFNM — FILE NAME 



FCBPSW — PASSCODE 



FCBFLG — FLAGS 
+ 



FCBCLA — LUNOs COUNT 



FCBCDF — DESCENDANTS CNT 



FCBAFD — FCB ADDRESS OF FIRST DESCENDANT 



FCBALS — FCB ADDRESS OF LAST SIBLING 



FCBANS — FCB ADDRESS OF NEXT SIBLING 



FCBAPF — FCB ADDRESS OF PAREN" 1 



FCBPRS — PHYSICAL RECORD SIZE 



FCBLRS — LOGICAL RECORD SIZE 



FCBPAS — PRIMARY ALLOCATION SIZE IN ADU 
FCBPAA — PRIMARY ALLOCATION ADDRESS 
FCBSAS — SECONDARY ALLOCATION SIZE 
FCBSAA — ADDRESS OF SAT BLOCK 
FCBEOM — END OF MEDIUM LOGICAL RECORD NUMBER 



FCBLLH — LDT LIST HEAD 

+ 



■+ 
i 

-+ 

i 

i 

■+ 
I 

i 

-+ 
I 

! 

■+ 
I 

I 

■ + 

! 

I 

-+ 
I 

I 

■+ 

I 

i 

- + 
I 

I 

■ + 



FCBBKM — END OF MEDIUM BLOCK NUMBER 

FCBOFM — END OF MEDIUM OFFSET 
FCBLRL — LOCKED RECORD LIST HEAD 



■+ 



Figure 6-13 File Control Block (FCB) — Part 1 of 2 
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+-_ + + 

>36 j FCBAPB — UNITS/BLOCK ! PCBBPA — BLOCKS /UNIT ! 

+ + + 

>38 j FCBPDT ~ DISK PDT ADDRESS \ 

+ + 

>3A ! FCBEXT — BLOCK COUNT FOR PILE EXTENSION ! 
i i 

i i 

+ + + 

N'ZTT' I "pn"Dvr<m ttittxp "nwm n ATTwm I •nn-niur-nn »*• <-\ -n -r -ra-r tit\ ttit»(-ioi I 

s jxj i j^jJAui — rixiii nAj. . ouuivj- i roBH.ru — nvuxrisiiLi riiRKjrD j 

>40 ! PCBRLA — REQUEST LIST ANCHOR | 

+ + 

>42 ! PCBLST — POINTER TO LAST ENTRY ON REQUEST LIST j 

* * 

>44 * 



Figure 6-1 ^ Pile Control Block (FCB) — Part 2 of 2 



Hex. 
Byte 



Field 
Name 



Description 



>00 



>02 



FCBLEN 



FCBRNM 



>04 


FCBFNM 


>0C 


FCBPSW 


>10 


FCBFLG 



Length in bytes of the FCB and any extensions 
(described later in this section). If there are no 
extensions, the value of this field is zero. 

The number of the directory file record that 
contains the file descriptor record for this file. 

File name (eight characters) 

Passcode, reserved for future extension. 

Flags, which are the same as in a file descriptor 
record except for bits 12-1"^. The flags have the 
following meanings: 

Bit Meaning 

0-1 File usage flags: 

00 No special usage 

01 Directory 

10 Program file 

1 1 Image file 

2-1 Data format: 

00 Binary 

01 Blank Suppressed 

10 Reserved for ASCII * print forms control 

1 1 Reserved 
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5-6 



Allocation type: 

Bounded 

1 Unbounded 

Pile type: 

00 Reserved for device 

01 Sequential 

10 Relative record 

1 1 Key indexed 

Write protection flag: 

Not write protected 

1 Write protected 

Delete protection: 

Not delete protected 

1 Delete protected (file cannot be deleted^ 

Temporary file flag: 

Permanent file 

1 Temporary file 



10 



Blocked file flag: 

Blocked 

1 Unblocked 



>12 FCBCLA 
>n PCBCDP 



>14 



>16 



PCBAPD 



PCBALS 



1 1 Alias flag: 

Not an alias 

1 An alias file name 

12-13 Most restrictive access applied to all users 
of the file: 

00 Exclusive write 

01 Exclusive all 

10 Shared 

11 Read only 

1 4-1 5 Reserved 

Number of LUNOs assigned to the file. 

Number of descendant PCBs in memory. Only a 
directory file may have descendants. Descendants 
are all files that are cataloged under this 
directory and any sub-directories. 

Address of the PCB of the first descendant (i.e., 
the first file cataloged under this directory that 
was accessed, and is still being accessed^. 

Sibling pointers. All PCBs of files cataloged under 
the same directory are laterally linked by these 
pointers, as described in Section 1. 
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>1A 



FCBAPF 



>1C 


FCBPRS 


>1E 


FCBLRS 


>20 


FCBPAS 


>22 


FCBPAA 


>24 


FCBSAS 


>26 


FCBSAA 



>28 



>?4 



FCBEOM 



>2C 


FCBBKM 


>30 


FCBOFM 


>32 


FCBLRL 



FCBLLH 



>^6 


FCBAPB 


>5 7 


FCBPBA 


>38 


FCBPDT 


>3A 


FCBEXT 


>?E 


FCBXCT 



Address of the FCB of the directory under which this 
file is cataloged. 

Size in bytes of a physical record of this file. 

Size in bytes of a logical record. 

Size in allocable disk units of the primary file 
allocati'T. 

Starting ADU number of the primary allocation. 

Size in ADUs of the secondary allocation. 

Address of te in-meraory copy of the secondary 
allocation table (SAT) for the file. ^he SAT is an 
exact copy of the last 64 bytes of the file 
descriptor record (FDR"! and is located in the system 
table area. 

The number of the logical record immediately 
following the last allocated logical record (end of 
medium). 

The physical record in which the file allocation 
ends (end of medium ") . 

The sector offset into the physical record that 
marks the end of medium. 

The head of a singly linked list of record lock 
tables, which are also located in the system table 
area, each of which points to a locked record of the 
file. 

Head of a linked list of all logical device tables 
that represent LUNOs assigned to this file. 

The number of ADUs per physical record. 

The number of physical records per ADU. 

The address of the PDT for the disk on which this 
file is written. 

Block count for file extension. 

Number of secondary allocations. 
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>3F 



FCBMFG 



>40 

>42 
>44 



FCBRLA 



FCBLST 



Flags as follows: 

Bit Meaning When Set: 



End of medium for this file has changed 
Data has been written into the file 
FCB is "busy 



Pointer to the next buffered I/O request for this 
file (1/0 requests for the same file are queued from 
the FCB until processed by file management). 

Pointer to the last buffered I/O request on the list 
for this file. 



6.4-1 KIF EXTENSION TO THE FCB. 

When an FCB represents a key indexed file, an extension to the FCB is 
used to contain additional information. Figure 6-14 shows the format 
of a KIF extension. 
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Hex. 
Byte 



>00 

>04 
>06 
>08 

>0C 
>0E 
>10 
>12 
>14 
>16 
>18 

>4C 



+• 



+- 



+ 



+ 



+ 



+^_. 



FCBTNB — TOTAL NUMBER OP BUCKETS 



. FCBCMD — COMMAND NUMBER 
ECBCLB — CURRENT LOG BLOCK NUMBER 






PCBEBQ — FREE BLOCK QUEUE HEAD 



■+ 



ECBBTR — B-TREE ROOTS BLOCK NUMBER 
PCBSBB — BLOCK NUMBER OE EIRST BUCKET 



•+ 



■+ 



ECBMRS — MINIMUM LOGICAL RECORD SIZE 
ECBKDB — NUMBER OE KEYS 



-+- 



FLAGS 



■+ 



■+ 



! CHARACTER COUNT OF KE^ 1 | REPEAT 
.+ + TP R SEC- 



OFFSET TO KEY 1 



Figure 6-1 4 FCB Extension for Key Indexed Files 



! ONDARY 

■+ —KEYS 
i 
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Hex. 


Field 


Byte 


Name 


>00 


FCBTNB 


>04 


FCBCMD 


>06 


FCBCLB 



>08 


FCBFBQ 


>OC 


FCBBTR 


>OE 


FCBSBB 


>10 


FCBMRS 


>12 


FCBKDB 



Description 



Total number of "buckets allocated in the file. 

The opcode of the current command (used for 
logging) . 

The physical record number of the currently used log 
block (see the discussion on key indexed files in 
Section 4) . 

The physical record number (block number) of the 
first record in a linked list of available records. 

The number of the first physical record containing a 
B-tree root. 

The number of the first physical record containing 
the first bucket. 

Minimum logical record size, in bytes, needed to 
contain all defined keys. 

These fields are in-memory duplicates of bytes 6-6? 
(>06->3F) of the disk resident key descriptor 
record. 



>4C 



6.4.2 QUEUE EXTENSION TO THE FOB. 

When the file represented by an FCB is a directory, a queue anchor of 
the form shown in Figure 6-1 is appended to the FCB. The queue 
anchored is a queue of TSBs of tasks waiting for access to the 
directory file. The queue is implemented to prevent both file 
management and file utility from updating the same directory record 
concurrently (e.g., if one task were writing to a file and another task 
were renaming the file at the same time) . 



Hex. 
Byte 



Field 
Name 



Description 



>00 FGBQUE Address of the TSB of the newest task waiting for 

access. 

>02 TSB address of the oldest task waiting for access. 

>04 FCBLOK TSB address of the task currently accessing the 

directory. 
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>06 FCBQFL Flags. Must have a value of >40. 

>07 Task Id of server. Must "be zero. 

>08 FCBQST Task state. Must be >1E. 

>09 Count of items on queue. 



6.4.3 RECORD LOCK TABLE (RLT). 

An RLT is a 10-byte "block of system table area that points to a file 
record that is locked. All locked records of a file are represented by 
a linked list of RLTs , ordered by an ascending disk address, which is 
headed by a word in the file control block. Each time a record is 
locked, file management builds a new RLT and links it on the list. 
Figure 6-15 shows the format of a record lock table. 



Hex. 
Byte 



>00 ; RLTLNK — TABLE LINK \ 

+ _„ + 

>02 j RLTLDT — LDT ADDRESS J 

+ + 

>04 ! RLTBLK — BLOCK NUMBER \ 

1 1 

i I 



■ + 



>08 I RLTOFF — OFFSET IN BLOCK j 

* * 



>0A * 



Figure 6-15 Record Lock Table (RLT) 



Hex. Field 

Byte Name Description 



>00 RLTLNK Link to the next RLT (0 = end of list). 

>02 RLTLDT Address of the logical device table that represents 

the LUNO assigned by the task that locked this 
record. 

>04 RLTBLK Number of the physical record of the file in which 

the locked logical record is written. 

>08->09 RLTOFF The logical record within the above addressed 

physical record that is locked. 
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6.4.4 PROGRAM PILE EXTENSION TO THE PCB. 

When an PCB represents a program file, an extension to the PCB is used 
to contain additional information. Pigure 6-16 shows the format of the 
program file extension. 



Hex. 
Byte 

* + ■ 

>00 iPCBMNT — MAX NO OP TASKS j PCBTO — DIRECTORY OPPSET 

+ -+ 

>02 ! PCBTR — TASK DIRECTORY ENTRY RECORD NUMBER 

+ . + 

>04 jPCBMNP — MAX NO OP PROCS \ PCBPO — DIRECTORY OPPSET 

+ + 



>06 



>OA 



+ 



PCBPR — PROCS DIRECTORY ENTRY RECORD NUMBER 



+- 



■+- 



■+ 



>08 IPCBMNO — MAX NO OP OVLYS J PCBOO — DIRECTORY OPPSET 



-+- 



■+ 



PCBOR ~ OVERLAYS DIRECTORY ENTRY RECORD NUMBER 



>OC * 



Hex. 


Pield 


Byte 


Name 


>00 


PCBMNT 


>01 


PCBTO 


>02 


PCBTR 


>04 


PCBMNP 


>05 


PCBPO 


>06 


PCBPR 


>08 


PCBMNO 


>OQ 


PCBOO 


>OA 


PCBOR 


>OC 


* 



Pigure 6-1 6 PCB Extension for Program Piles 



Description 



Maximum number of task entries in the file. 

Task directory entry offset. 

Task directory entry record number. 

Maximum number of procedure entries in the file 

Procedure directory entry offset. 

Procedure directory entry record number. 

Maximum number of overlay entries in the file. 

Overlay directory entry offset. 

Overlay directory entry record number. 
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6.5 LOGICAL DEVICE TABLE (LDT) 

Logical device tables are built in the system table area by the file 
utility assign LUNO processor. Whenever a LUNO is assigned to a file or 
device, an LDT is built to represent the logical unit "to the system. 
Figure 6-1^ shows the format of an LDT. 



Hex. 
Byte 



>00 
>02 
>04 
>06 
>08 
>0A 
>0C 
>0E 

>12 

>16 
>18 
>1A 
>1C 



+- 



+■ 



+- 



+- 



+- 



+ 



LDTPDT — PDT ADDRESS 



-+- 



LDTLUN -- LUNO 



+ 

! LDTIOC — START I/O COUN^i 
+ + 

LDTFLG — FLAGS \ 

1 

1 

+ 



LDTLDT — LDT LINK 



LDT T SB — USER TSB ADDRESS 



LDTELL — PILE LINK 



LDTPCB — FCB ADDRESS 



+- 



+- 



LDTLRN — CURRENT LOGICAL RECORD NUMBER 



LDTBN — CURRENT BLOCK NUMBER 



+- 



LDTOCB — OFFSET IN CURRENT BLOCK 
LDTBLK — BUFFER BEET ADDRESS 



-+- 



LDTORC — 



OUTSTANDING REQS ! 



LDTNU — NOT USED 



Note: Bytes >00->09 are the same for file and 

device LDTs. Bytes >10->1B are used only 
for file LDTs. 



Figure 6-1 7 Logical Device Table (LDnM 



•+ 



-+ 



■+ 
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Hex. Field 

Byte Name Description 

>00 LDTPDT Address of the PDT to which the LUNO is assigned. 

For LUNOs assigned to files, this is the PDT for the 
disk unit on which the file is written. 

>02 LDTLUN The LUNO which this LDT represents. 

>0J> LDTIOC The number of initiate I/O operations currently 

being performed at this LUNO. 

>04 LDTFLG Flags as follows: 

Bit Meaning 

This LDT is used to anchor a list of LDTs 
(e.g. , in a KSB) . 

1-2 Access privileges: 

00 Exclusive write 

01 Exclusive all 

10 Shared 

1 1 Read only 

? The file to which the LUNO is assigned was 
created by the Assign LUNO SVC . 

4-5 Scope of LDT anchor (i.e., what kind of LUNO,: 

00 Task local 

01 Station local 

10 Global 

1 1 Undefined 

6 Deferred write error. 

7 File is forced write. 

P LUNO is a system LUNO (cannot be released^. 

9 LUNO assigned to a file. 

10 LUNO is busy. 

11 Event mode is locked in record mode. 

12 Initiate I/O is being performed. 

13 Abort I/O is being performed. 

14 Unblocked access. 

15 Print flag. 

>06 LDTLDT Link to the next LDT in the LD m inverted tree 

structure described in Section 1 . 

>08 LDTTSB TSB address of the task that opened the LUNO. 
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■*■ "tt"^" ^t- -X - -X" -X - "X - -X" "X - "Jt - ^f" "M" ■Jf" , X' - i4 - -)t , ')f''9€'-it , -X"?fr-^f - -^■-X- -?(■ -3I--X" ^ -Jt - 4t "^ -??• ■?(■ -^t* ■Jt' -5^ -H" "X- -7^- -Jf - -Jf-"^ -Jf - -)?" ■?{■ -^ -Jf - -^fr -^ ■?f"-X"4^' ■?t'44 - •%■ "^f*-^ - -Sf - ■?!■ ^ ■?(■ •)f" , 5f"X" ■??" ■X"^" ■}(■ "Jf" 

* The remaining fields (bytes >OA through >1lO are only defined for * 

* LDTs that represent LUNOs assigned to files. When a LUNO is * 

* released, or the task that assigned the LUNO terminates, the LDT * 

* is released "by the file utility Release LUNO routine. * 
******************************************************** 



>OA 



LDTFLL 



>oc 


LDTFCB 


>OE 


LDTLRN 


>12 


LDTBN 


>16 


LDTOCB 


>18 


LDTBLK 



>1A 


LDTORC 


>1B 


LDTNU 


>1C 


* 



Link to the next LDT representing a LUNO assigned to 
the same file. All LDTs assigned to the same file 
are linked together, and anchored in the file 
control block. 



Address of the file control block for the 
which the LUNO is assigned. 



'■n «» 



to 



The number of the logical record that is currently 
being accessed. 

The number of the physical record that is currently 
being accessed. 



The offset into the physical record to th« 
logical record. 



current 



The beet address of the buffer that contains the 
last physical record transferred (read or written) 
through this LUNO (zero if the buffer has been 
released) . 

Number of outstanding requests for I/O to this LUNO. 

Not used. 



6,6 BUFFERED CALL BLOCK 

Whenever a supervisor call that is processed by a queue serving routine 
is issued, the call block is buffered in the system table area and 
queued for the SVC processing routine. The first four words of the 
buffer contain the following system overhead. 

Hex. Field 

Byte Name Description 

>00 Link to the next entry in the queue. 

>02 Address of the TSB of the task issuing the SVC . 

>04 Address of the call block within the calling task. 

>06 Address of the LDT to which an I/O operation is 

directed (used only ^or I/O SVCs^ . 

The remainder of the buffer contains the call block and any extension 
blocks or data buffers. 



9^91 5^-9701 



6-37 



Texas Instruments 



Data Structures 



System Design Document 



6.7 TASK STATUS BLOCK (TSB) 

Tasks are represented within DX10 by a task status block (TSB"). TSBs 
are built in the system table area by the bidding routines TMBIDO and 
TM$BID. A TSB is released by the termination task, TMDGN, when a task 
terminates, unless the task is a queue server. TSBs of inactive queue 
servers are not released unless more system table area is needed. 
Figure 6-18 shows the format of a task status block. 

Hex. 

Byte ^ 



>00 
>02 
>04 
>06 
>08 
>0A 
>0C 
>0E 
>10 
>12 
>14 
>16 
>18 
>1A 



+ 



+ 



+ 



+ 



+■ 



+• 



+- 



+- 



+■ 



+- 



+■ 



+■ 



+- 



TSBQL ~ QUEUEING LINK 
TSBWP — ACTIVE WP 



TSBPC — ACTIVE PC 
TSBST — ACTIVE ST 



•+- 



TSBPRI — PRIORITY ! TSBSTA ~ TASK STATE 

+ 

TSBFLG — TASK FLAGS 

TSBEAC — TRANSFER VECTOR ADDRESS 



TSBID — INSTALLED ID 



TSBRID — RUN ID 



-+■ 



TSBSMF ~ SAVED MAP FILE ADDRESS 



TSBLNK — FIXED TSB LINK 
TSBKSB — KSB ADDRESS 



TSBFL2 ~ TASK FLAGS (WD2) 



TSBAR1 — BID PARAMETER f 1 ) 



TSBAR2 -- BID PARAMETER (2) 



■+ 



■+ 



-+ 



-+ 



-+ 



■+ 



■+ 



+ 



+ 



+ 



+ 



+ 



+ 



■+ 



Figure 6-18 Task Status Block (TSB) — Part 1 of ^ 
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-+ 



>1C 


i 

i 




+ 


>1E 


i 

i 




+ 


>20 


i 

i 




+ 


>22 


i 

i 




+ 


>24 


i 

i 




+ 


>26 


i 

i 




+ 


>28 


i 

i 




+ 


>2A 


i 
i 




+ 


>2C 


i 

i 




+ 


>2E 


i 

i 
i 




i 
+ 


>32 


i 

i 




+ 


>34 


i 

i 




T 


>36 


1 

1 




+ 


>38 


1 

1 




+ 


>3A 


1 

1 




+ 


>3C 


1 

! 




+ 


>3E 


1 

1 




+ 


>40 


1 

1 




+ 


>42 


1 

1 




+ 


>44 


1 

1 




+ 


>46 


1 

1 




+ 


>48 


1 

1 




+ 


>4A 


1 

1 




+ 


>4C 


1 

1 




+ 


>4E 


1 

1 



TSBALT — ALTERNATE TSB ADDRESS 
+ 



TSBCHR — 91V911 CHAR {TSBIOC — TILINE I/O COUN r 



-+- 



TSBPR1 — PSB ADDRESS (PROC 1) 
TSBPR2 — PSB ADDRESS fPROC 2) 



TSBPCB — PROGRAM PILE TCB ADDRESS 
TSBERC — DIAGNOSTIC ERROR CODE 



+ 



+ 



+ 



+ 



■+ 



TSBWPD — DIAGNOSTIC WP 
TSBPCD — DIAGNOSTIC PC 



■+ 



■+ 



TSBSTD — DIAGNOSTIC ST 



■+ 



TSBTD1 — TIME DELAY COUNTER 
TSBTD2 



-+ 



TSBML1 — MAP LIMIT 1 

TSBMB1 — MAP BIAS 1 

TSBML2 — MAP LIMIT ? 



■+ 






TSBMB2 — MAP BIAS 2 
TSBML3 — MAP LIMIT ^ 



TSBMB^ — MAP BIAS 3 

+ . + 

TSBPRP — FIXED PRIORITY j TSBMRG — TASK REGISTER NO 
+ . + 



TSBPAR — PARENT TSB ADDRESS 
TSBSON — OLDEST SON TSB ADDRESS 



■+ 



-+ 



TSBBR1 — OLDER SIBLING TSB ADDRESS 
TSBBR2 ~ YOUNGER SIBLING TSB ADDRESS 



TSBBLN — BEET LENGTH OP PROGRAM 
TSBTON — OVERLAY NUMBER 



■+ 



•+ 



+- 



TSBOAD — ADDRESS OP OVERLAY AREA DES. 
TSBTO — TIME TASK SUSPENDED 

Pigure 6-18 Task Status Block (TSB) — Part 2 of ^ 



■+ 



■+ 



■+ 



•+ 



■+ 



-+ 
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>50 



>52 
>5^ 



>5A 

>5C 
>5E 
>60 
>62 

>64 

>66 



+- 



+- 



TSB^I — NUMBER OP TIME SLICES REMAINING 



TSBSCR — SCRATCH FOR GETMEM 



+- 



TSBRLL -- LINK TO NEXT ROLLED TASK 



+- 



■+ 



>56 j TSBRRN — ROLL PILE STARTING PHYSICAL RECORD NUMBER 



+- 



+- 



+- 



+■ 



TSBRRL — NUMBER OP ROLL PILE RECORDS 



TSBLDP — LOCAL LDT LIST FLAGS 



TSBLDA — LOCAL LDT LIST ADDRESS 
+- 



TSBEOR — EOR COUNT 



TSBIIP — I/O COUNT 



■+- 



TSBSER — QUEUE ANCHOR ADDRESS 



TSBTSC — TASK SENTRY COUNT 



-+ 



+ 



+ 



Hex. 
Byte 



>02 



>08 



>OQ 



Figure 6-1 R Task Status Block (TSB) — Part ^ of * 
Description 



Field 
Name 



TSBWP, 
TSBPC, 
TSBST 



TSBPRI 



TSBSTA 



Link to the next TSB on the queue, when this TSB is 
queued. 

The saved context f workspace pointer, program 
counter and status register values') for the task. 
When the task is scheduled to execute, these saved 
values are used to begin execution. 

Task priority (0, 1,2,^, or >81 , >«2, >8^, ..., 
>¥¥) where >81 is real-time priority 1 and >FF is 
real-time priority 12" 7 . 

Task state as shown in table 6-1 . 
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Table 6-1 ^ask State Codes 



Task 

State Significance 



00 Active task, priority level 
^ ' rtuuj.vc ufctsK., pnoricy ievei i 

02 Active task, priority level 2 

03 Active task, priority level ^ 

04 Terminated task 

05 Task in time delay 

06 Suspended task 

07 Currently executing task 

08 Reserved 

09 Task awaiting completion of 1/0 

0A Task awaiting assignment of device for 1/0 

0B Task awaiting disk file utility services 

0C Reserved 

0D Task awaiting file management services 

0E Task awaiting overlay loader services 

OF Task awaiting initial load 

10 Reserved 

1 1 Task awaiting disk management services 

12 Task awaiting tape management services 

13 Waiting on system overlay loader services 
H Waiting on task driven SVC processor 

15 Task waiting on GETMEM request 

16 Not used 

1 7 Suspended for co-routine activation 

18 Task waiting on termination task services 

19 Task awaiting completion of any I/O 
1A Waiting on MM$END door 

1B Task eligible for rollout when requested I/O is complete 

1C Task activated while roll in progress 

1D Suspended for initiate I/O threshold 

1E Suspended for locked directory 

1E Suspended for task management directory buffer 

24 Task suspended for queue input 

EP Dummy task state 
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Hex. 
Byte 

>0A 



>0C 
>0E 
>0F 
>10 

>12 



>H 



Field 
Name 



TSBFLG 



TSBEAC 
TSBIID 
TSBRID 
TSBSMF 

TSBLNK 



TSBKSB 



Description 



First word of task flags. The flags are as follows 



Meaning When Set 




12 
15 

H 
1^ 



System task (Hardware and 

software privilege) 

Privileged task (Software) 

Memory resident task 

Take end action on error 

Roll out candidate 

Rolled out 

Abort/terminate task 

Activate call outstanding 

Reactivate "bidding task at termination 

Serially reusable task 

Task quieting in progress 

Initial bid 

Leave task alone; do not abort 

Task is under control of alternate 

TSB 

SCI flag for scanning TSB chain 

Task is replicated image 



Transfer vector address. 

Installed task ID. 

Runtime ID assigned by system. 

Address in the TSB of the saved 
values (bytes ^2-^D) . 



map file register 



Link to the next TSB in the fixed list of TSBs. All 
TSBs in the system table area are linked onto this 
list when they are created. The list may be 
searched to find a task with a given runtime ID by 
the routine named TMTSCH (e.g., to kill the task). 

Address of the KSB of the terminal with which this 
task is associated (i.e., the task was bid from the 
terminal) . 
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>16 



TSBFL2 



>18 



>1C 



>26 



>28 



>2E 



>32 



TSBAR1 



TSBALT 



>1E 


TSBCHR 


>1E 


TSBIOC 


>20 


TSBPR1 


>22 


TSBPR2 


>24 


TSBFCB 



TSBERC 



TSBWPD, 
TSBPCD, 

TSBSTD 



TSBTD1 



TSBML1 



Task flags as follows: 
Bit Meaning When Set 




1 
2 

=2- 

T 

5 
6 

■Z- 

8 
9 

10 
44- 



12 



Task to "be suspended next time it executes 

Task is "being controlled 

SVC traps to be taken when specified 

SVC switch: when 0, SVC traps are taken 

Execution stopped b"" - scheduler 

Execution stopped by trapped SVC 

Execution stopped by XOP 15,15 ('breakpoint) 

Dynamic priority management 

Roll in progress 

Task activated 

Initiate followed by execute I/O 

Extend time slice 

End action available for task 

a( 



1$-15 Not used 

The two parameters that may be passed to the task by 
the Bid SVC, and accessed by the task using the Get 
Bid Parameters SVC. 

TSB address of the alternate task. The alternate 
task is executed in place of this task. 

91*5/911 character. 

Number of outstanding TILINE I/O operations. 

Address of the procedure status block (see paragraph 
6.7.T) for attached procedure 1 (zero if nonel . 

PSB address for procedure 2 ''zero if none). 

Address of the ECB that represents the program file 
on which this task is installed. 

Error code that describes the error that caused the 
task to terminate (used by termination task). 

The context (WP, PC, and ST registers) of the task 

at the time an error forced the task to terminate or 

a( 

take end action (used by the termination task).) 

These These values are returned on a Get End Action 

Status SVC. 

Number of system time units remaining before this 
task will be reactivated from its time delayed state 
(52 bits.) 

The map register values to be used when this task 
executes . 
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>3E 
>"5P 



>40 


TSBPAR 


>48 


TSBBLN 


>4A 


TSBTON 


>4C 


TSBOAD 



>4E 
>50 

>54 



>56 

>5A 

>5G 
>5E 

>60 



TSBPRF Nap flags. Fixed priority of task. 

TSBMRG- The offset into the saved map file that marks the 
limit register that maps the task segment ''i.e., 0, 

4, or 8).' 

TSB family tree pointers as described in Section 1 . 

Length of the entire progra (task and procedures) 
in "beets (^2-byte blocks) . 

The number of the system overlay in which this task 
was last executing ''used for system tasks only) . 

The address of the overlay area in which the above 
overlay was loaded (the overlay MUST be reloaded in 
the same place") . 

TSBTO Number of time slices this task has been suspended. 

TSBT1 Number of time slices still allotted to this task as 
the minimum number of time slices it must receive 
before it can be forcibly rolled-out by an equal 
priority task. 

TSBSCR Scratch used by the Get Memory SVC processor and the 
system overlay loader. 

TSBRLL Link to the TSB or PSB that represents the next 
rolled segment. The TSB or PSB of each rolled task 
or procedure is linked onto a list of rolled 
segments. The list is kept in order by increasing 
roll file record number; i.e., segments that were 
written at the beginning of the roll file are at the 
beginning of the list. This linked list serves as a 
directory into the roll file, so that the various 
rolled segments can be retrieved for roll-in. 
Further roll information is kept in TSBs or PSBs. 

TSBRRN Number of the physical record in the roll file that 
begins the rolled image of the task segment. At 
initial bid time, this is the program file record 
number. 

TSBRRL Number of roll file records occupied by the rolled 
task image. During initial bid, this is the length 
of the task in bytes. 

TSBLDF Task local LDT list flags: bit is the LDT anchor. 

TSBLDA Pointer to the first task local LD^, or the station 
local LDT list anchor Cif there are no task local 
LDTs). 

TSBEOR Number of I/O end-of-records that need to be 
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processed for this task. If this field, is non-zero, 
the device driver task (VD? 1 ) ± s given the next time 
slice that would otherwise have been awarded to this 
task. 

>61 TSBIIP The number of I/O operations outstanding for this 

task. 

— — — -lie rx^urcoo ui uny H.ncnor lor xne queue served by 
this task fused only for queue servers). 

>64 TSBTSC The task sentry count. 

>66 * 



6.8 PROCEDURE STATUS BLOCK (?SB) 

Each procedure being accessed by a task within DX10 is represented by a 
procedure status block, just as tasks are represented by^SBs. When a 
task is bid, the bidder task, TMSBID, checks to see if the task has any 
attached procedures. If so, the bidder task scans the fixed list of 
PSBs anchored in the D*DATA module to see if the procedures are already 
in memory. If not, TMSBID builds a PSB ^or the procedures. 

A PSB is built in the system table area and linked on the fixed list of 
PSBs. Figure 6-19 shows the format of a PSB. 
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Hex. 
Byte 



>00 
>02 
>04 
>06 
>08 
>0A 
>0C 
>0E 
>10 
>1 2 
>14 



Hex. 
Byte 

>00 

>01 



>02 

>04 
>06 



* +- 

PSBID — PROCEDURE ID ! 



+ 



+ 



+■ 



+ 



PSBFLG ~ FLAGS 



■+ 



PSBADD — PROCEDURE ADDRESS 



PSBLEN — PROCEDURE LENGTH 



-+ 



PSBLNK — FIXED PSB LINK 



-+ 



PSBFCB — PROGRAM FILE FCB ADDRESS 



+■ 



■+ 



PSBATT — NO. ACTIVE TASKS j PSBTIM — NO. IN-MEM TASKS 



+- 



•+- 



PSBRLL — LINK TO NEXT ROLLED SEGMENT 



+- 



PSBRN1 ~ RELATIVE RECORD NUMBER IN ROLL 



+- 



■+ 



PSBRN2 — FILE/PROGRAM FILE 



+- 



PSBRRL — NUMBER OF ROLL FILE RECORDS 



Figure 6-1 P Procedure Status Block (PSB^ 



Field 

Name 



PSBID 



PSBFLG 



Description 

ID assigned to the procedure when it was installed 
on the program file. 

Flags as follows: 

Bit Meaning When Set 



Memory resident procedure 

This is the initial bid of the procedure 

Procedure is rolled out 

Procedure roll is in progress 

Writable control storage XOP 

PROC is write protected 

PROC is execute protected 



PSBADD 

PSBLEN 
PSBLNK 



Address of the starting beet f^-byte block of 
memory^ of the procedure. 

Length of the procedure in beets. 

Link to the next PSB in the fixed list of PSBs ^zero ( 
if at end of lisO . 



Texas Instruments 



6-4£ 



Q7Q1 tS7_Q^CM 



System Design Document 



Data Structures 



>08 

>0A 
>0B 

>0C 

>0E 
>10 
>12 

>14 



PSBFCB 

PSBATT 
PSBTIM 

PSBRLL 

PSBRN1 
PSPRN2 
PSBRRL 



Address of the ECB for the program file on which the 
procedure is installed. 

Number of active tasks that share this procedure. 

Number of active tasks with memory (not rolled) that 
share this procedure. 

T.l'nV +r> -f-Vlo r,av+ yi^illaA C3Q run oyi+ f <-i «-> t*. •> r-> o A^/i^-nAT^^A 

a-ij-j.ii.>- u^ \jxx<.s 1U-AU i. \J _'..'. C5 1 1 OCp,I!lClHj \ oamc CIO U^OUi iut:u 

for TSBs) . 

Relative record number in roll . 

Pile/program file. 

Number of roll file records occupied by the rolled 
procedure. During the initial bid, this is the 
length of the procedure in bytes. 



A PSB may be released to the system table area by the memory management 
routine named RELPSB. The PSB may only be released if the procedure 
has zero attached active tasks, -in which case both the procedure memory 
and the PSB are released. 



6.9 TIME ORDERED LIST (TOD 

As described in Section 1, all allocated blocks of memory (excluding 
the system table area) are linked on a doubly-linked, circular, time 
ordered list. This is done in order to support the least recently used 
algorithm used by DX10 memory management to select blocks of memory for 
rollout. 

Blocks of memory that may be on the TOL are: task memory, procedure 
memory, and file management blocking (I/O) buffers (maximum of "*0 
buffers on TOL). Whenever a block of memory is accessed (i.e., 
executed if it is a task; read or written if it is' a buffer), it is 
removed from its current position on the TOL, and relinked at the 
beginning of the list when the access is ended. An exception to this 
rule is procedure memory, which is not removed from the TOL when 
procedures are used. Procedure blocks, therefore, tend to go to the 
end of the list. 

The overhead involved in maintaining the TOL consists of a TOL header, 
located in the DSDATA module, and an overhead beet ("^2-byte block) at 
the beginning of each allocated segment of memory. The overhead beet 
is created by either the task loader (for tasks and procedures) or 
buffer management (for blocking buffers). Figure 6-20 shows the format 
of a TOL beet. Note that an overhead beet is also used to maintain the 
linked list of free memory blocks (see paragraph 6.11). 
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Hex. 
Byte 

>00 ! TOLLEN — BLOCK LENGTH ! 

+ + 

>02 ! TOLPTR — POINTER ! 

>04 ! TOLELK — EORWARD LINK ! 

>06 ! TOLBLK — BACK LINK ! 

>08 ! TOLTYP — BLOCK TYPE ! 

+ 1 

>OA ! ' 

NOT USED 

i ! 

+ — . + 

>18 ! BUFFLG — FLAGS ! 

+ + 

>1A i BUERLN — BUFFER LENGTH ! 

+ + ! 

>1C ! ' IJ3ED 

j BUFBLK — PHYSICAL RECORD NUMBER ! ONLY 

i ! FOR 

i ! BUFFERS 

* * ! 

>20 * 

Figure 6-20 TOL Overhead Beet 

Hex. Field 

Byte Name Description 

>00 TOLLEN Length, in "beets, of the attached block of memory 

including this overhead beet. 

>02 TOLPTR Pointer, which varies depending on how this "block is 

"being used: 

Task — Pointer to TSB 

Procedure — Pointer to PSB 

Buffer ~ Pointer to LDT 

Free block — Pointer to next free block 

>04 TOLFLK Forward link to next oldest block. 

>06 TOLBLK Back link to next youngest block. 
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>08 TOLTYP Block type as follows: 

1 = task 

2 = procedure 
^ = free "block 

= "blocking "buffer 
-1 « list header 

>0A N t used. 

>18 BUFFLG Flags as follows: 

Bit Meaning When Set 



Buffer is "busy 

Write this block 

This is the memory resident buffer 

Release this "buffer immediately 



>1A 
>1C 

>20 



BUFRLN 
BUFBLK 



Length of buffer (excluding overhead beet) in bytes. 

Number of the file physical record that is buffered 
in this buffer. 



6.10 SYSTEM LOG PARAMETER BLOCKS (SLPB) 

Whenever a message is to be written to the system log, the message 
information is queued to the system log message aueue in the form of a 
12-byte system log parameter block (SLPB'i plus extensions. The SLPB is 
created by different routines depending upon the source of the log 
message as follows: 



Source 
Device Errors 

Task Errors 

User Messages 
Log Messages 
Memory Errors 



Creation Routine 

SYSLQ, called by DDTEND, the end record 
and statistic messages processor. 

SLPBQC, called by TM*DEN, the diagnostic 
task. 

SLSVC, the system log SVC processor. 

SLMEOT, the system Tog formatter. 

Non-correctable errors in TM$INT; 
correctable errors in TM^SHD. 



The SLPBs are queued for the system log formatting and output task, 
SLMEOT, which formats each SLPB and writes the message to the logging 
device and/or files. Figure 6-21 shows the format of the SLPB. 
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Hex. 
Byte 

* * 

>00 I SLPB — QUEUE LINK ! 

+ 1 

>02 ! SLDAY — JULIAN DAY . 

>04 ! SLHOUR — HOUR ! SLMIN — MINUTE ! 
+ + 1 

>06 ! SLFLAG — SLB FLAGS | SLXKEY — EXTENSION KEY I 
+ + 1 

>08 ! SLTYPE — ERROR Type 

1 i 

>oc * 

Eigure 6-21 System Log Parameter Block 

Hex. Eield 

Byte Name Description 

>00 SLPB Link to the next "block on the queue. 

>02 SLDAY Julian day. 

>04 SLHOUR Hour. 

>05 SLMIN Minute. 

>06 SLFLAG- Flags as follows: 

Bit Meaning When Set 

Subsequent messages have been lost 
1 - n Not used 

>0 r 7 SLXKEY Extension key as follows: 

Device extension with controller image 

1 User call extension 

2 Memory error extension 

3 Statistics extension 

4 Interrupt extension 
6 Task extension 

8 Cache memory extension 

9 Device extension with PRB 

>08 SLTYPE Error type ftask, DS01 , etc.^ 
>0C * 
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Depending upon the source of the message? various extension blocks are 
appended to the SLPB. The type of extension block to be appended is 
indicated by the extension key in the SLPB. Thp format of each of the 
extension blocks is shown in the following paragraphs. 

6.10.1 DEVICE EXTENSION WITH CONTROLLER IMAGE (SLXKEY = 0). 

Figure 6-22 shows the format of the SLPB Device Extension with 
Controller Image. 

Hex. 

Byte 

* + * 

>0C | SLEC — DX10 ERROR CODE | SLINID — INSTALLED ID | 
+ + + 

>0E | SLRNID — RUNTIME ID | SLSTID — STATION ID | 
+ +__. + 

>10 | SLLUNO — LUNO | SLRTRY — RETRIES | 

+ + + 

>12 |SLSORF — S=SUCCESS F=FAIL| NOT USED | 

+ + + 

>14 |SLACNT— # AFTER IMAGE WDS | SLBCNT — # BEFORE IMAGE WDS | 
+ + + 

>16 | | 

AFTER IMAGE 

i i 

>26 | | 

~ BEFORE IMAGE 

I | 

>3C * 

Figure 6-22 SLPB Device Extension With Controller 
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6.10.2 USER CALL EXTENSION TO SLPB (SLXKEY = 1). 

Figure 6-23 shows the format of the User Call Extension to the SLPB, 

Hex. 
Byte 



>0C I SLMLEN — MESSAGE LENGTH | USER MESSAGE BEGINS HERE 

+ + (255 BYTES MAX.) 



Figure 6-23 User Call Extension to SLPB 



6.10.3 MEMORY ERROR EXTENSION TO SLPB (SLXKEY = 2). 

The Memory Error Extension applies to 16K RAMs only. Figure 6-24 shows 
the format of the Memory Error Extension to the SLPB. 

Hex. 
Byte 



>0C 



SLROW — ROW IN ERROR 



>0E 



SLBIT — BIT IN ERROR 

(0-15, 6 ECC bits) J I 

+ — — ~+ 

SLCORR— CORRECTABLE ERROR? I SLBAS2 — CONTR BASE ADDR 
(Y=yes, N=no) | 

+ + + 

>10 I SLMEM2— AMOUNT OF MEMORY I SLTYP2 -- CONTROLLER TYPE 
I (Controller only) | I 

« + + + 

>12 SLADR2 — TCPS ADDRESS OF CONTROLLER I 



>14 * 



Figure 6-24 Memory Error Extension to SLPB 
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6.10.4 STATISTICS EXTENSION TO SLPB (SLXKEY =3). 

Figure 6-25 shows the format of the Statistics Extension to the SLPB, 

Hex. 
Byte 



SLDEV3 — DEVICE NAME 



SLREAD — 


- TOTAL READ 


OPERATIONS 


SLWRT — 


TOTAL 


WRITE 


OPERATIONS 


SLTOT — 


TOTAL 


OTHER 


OPERATIONS 



>oc 



>io i 

4 

>12 | 

+ 

>14 | 

>16 * 

Figure 6-25 Statistics Extension to the SLPB 

6.10.5 INTERRUPT EXTENSION TO SLPB (SLXKEY = 4). 

Figure 6-26 shows the format of the Interrupt Extension to the SLPB. 

Hex. 

Byte 

+ _ + + 

>0C | SLINT — INTERRUPT LEVEL | SLCHAS — CHASSIS OF INT I 
+ + + 

>0E |SLPOS — POSITION IN CHASSIS | RESERVED | 

+ + 

>10 | SLDEV4 — DEVICE NAME IF KNOWN 



>14 * 



Figure 6-26 Interrupt Extension to the SLPB 



939153-9701 (Change 1) 



6-53 



Texas Instruments 



Data Structures 



System Design Document 



6.10.6 TASK EXTENSION TO SLPB (SLXKEY = 6). 

Figure 6-27 shows the format of the Task Extension to the SLPB. 

Hex. 

fyte_ # + # 

>0C | SLEC — DX10 ERROR CODE | SLINID ~ INSTALLED ID | 

+ . + + 

>0E SLRNID — RUNTIME ID | SLSTID ~ STATION ID | 

| -— + + 

>10 I SLWP6 — WP (WORKSPACE POINTER) | 

i 1 

>12 I SLPC6 — PC (PROGRAM COUNTER) | 

i J 

>14 I SLST6 — ST (STATUS REGISTER) | 

i + 

>16 * 

Figure 6-27 Task Extension to the SLPB 



6.10.7 

Figure 

Hex. 
Byte 

>0C 
>0E 
>10 
>12 
>14 



CACHE MEMORY EXTENSION TO SLPB (SLXKEY = 8) . 
6-28 shows the format of the Cache Memory Extension to the SLPB 



SLBANK — CACHE BANK SLPARA — ADDRESS PARITY 
(A or B) IN BANK A (G or B) 


SLPARB — ADDRESS PARITY 1 SLBAS8 — BASE ADDRESS 
IN BANK B (G or B) | OF CONTROLLER 


SLMEM8 — AMOUNT OF 
CONTROLLER MEMORY 


SLEVEN — IS ERROR ON 
EVEN COORDINATE? (Y or N) 


J SLADR8 — TCPS ADDRESS OF CONTROLLER 



Figure 6-28 Cache Memory Extension to the SLPB 
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6.10.8 

Figure 

Hex. 
Byte 



SLPB DEVICE EXTENSION WITH PRB (SLXKEY = 9) . 
6-28 shows the format of the SLPB Device Extension with PRB, 



>0C 
>0E 
>10 
>12 
>14 



| SLEC — DX10 ERROR CODE 

4—__ ______ _._._- — — — — — — - 


1 


SLINID — INSTALLED ID 


| SLRNID — RUNTIME ID 

+__ _ _ _ __ _ 


1 


SLSTID — STATION ID 


| SLLUNO — LUNO 




SLRTRY — RETRIES 


|SLSORF — S=SUCCESS F=FAIL| 

+ +_ 


NOT USED 



SLPRB — PRB THAT CAUSED THE 
DSR TO REPORT THE ERROR 
(12 Bytes) 



>20 



Figure 6-28 SLPB Device Extension with PRB 



6.11 SYSTEM OVERLAY TABLE (OVT) 

The system overlay table (OVT) is a vector table that contains the 
addresses of many system routine entry points, data structures, lists, 
and queue anchors. It is used by disk resident system tasks that are 
not linked with the DX10 memory resident code, but which must refer to 
and/or use information contained therein. The address of the vector 
table may be obtained via a special SVC, Get System Pointer Table 
Address. By using the table address as a base register value, a system 
task can refer to any of the addresses within the table by name. A 
template of the overlay table, showing the labels defined, follows. 
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-**•*-* ****** •**-*-*-** ************* *********************************** 

( OVT ^ * 

*************************************** 

STAR? OP ^SB'S 
ADDR SYSTEM TIME UNITS /SEC 
START OP PSB'S 
. ADDR PIXED TASK ID BIT MAP 

ADDR SYSTEM PROGRAM PILE PCB PT 

CURRENT EXECUTING TASK 

BREAKPOINT TABLE 

TASK SEARCH UTILITY 

ADDR OP PATHNAME OP SYSTEM PROG 

TSB CLEAN UP 

PUTIL/UNLOAD LOCKOU m 

PUTIL PDT CURRENTLY IN USE 

START OP PDT'S 

START OP LDT'S 

REM. SPEC. ENT. PROM SPEC. QUEU 

BID TASK ROUTINE 

BUILD TREE LINKAGE 

USER RESTART ID 

CRT 'HELP' KEY DISABLE SWITCH 

SYSTEM LOG DATA 

ALLOCATE USER MEMORY ROUTINE 

MAP BUFFER INTO ADDRESS SPACE 

START OF NON-LINKED TSB'S 

START OP SYSTEM TABLE 

SIZE OP SYSTEM m ABLE 

PTR TO ACTIVE QUEUES 

ADDR OP ^IME DELAY LIST ANCHOR 



-* 




OVERLAY 


TABLE 


************************* 


OOOO 






DORG 





0000 


0000 


TSKLST 


DATA 





0002 


0000 


UPS 


DATA 





0004 


0000 


PSBLST 


DATA 





0006 


0000 


PIDMAP 


DATA- 





0008 


0000 


PF$FCB 


DATA 





OOOA 


0000 


ETSK 


DATA 





OOOC 


0000 


BPT 


DATA 





OOOE 


0000 


TSKSCH 


DATA 





0010 


0000 


SYSPP 


DATA 





0012 




MMSRLM 


BSS 


4 


0016 


pppp 


FSFLG 


DATA 


-1 


0018 


0000 


PUTPDT 


DATA 





001 A 


0000 


PDTLST 


DATA 





001 C 


0000 


LDTLST 


DATA 





001 E 




TMSQRM 


BSS 


4 


0022 




TMBIDO 


BSS 


4 


0026 




TMTREE 


BSS 


4 


002A 


0000 


RSTRID 


DATA 





002C 


0000 


RSTRSW 


DATA 





002E 


0000 


SLDATA 


DATA 





0030 




MM$FND 


BSS 


4 


0034 




BMSMPB 


BSS 


4 


0038 


0000 


TSKSTR 


DATA 





003A 


0000 


SYSTAB 


DATA 





00"5C 


0000 


TABSIZ 


DATA 





003E 


0000 


AQPTRS 


DATA 





0040 


0000 


TDL 


DATA 





0042 


0000 


KB TAB 


DATA 





0044 




SLPBQC 


BSS 


4 


0048 


0000 


SCIBMX 


DATA 


o 


004A 


0000 


SCIPMX 


DATA 





004C 


0000 


MAPSHD 


DATA 





004E 


0000 


YEAR 


DATA 





0050 


0000 


UAHEAD 


DATA 





0052 


0000 


SAHEAD 


DATA 





0054 


0000 


KTSKWP 


DATA 





0056 


0000 


KTSKPC 


DATA 





0058 


0000 


CURMAP 


DATA 





005A 


0000 


OADPTR 


DATA 





005C 


0000 


OVLYQ 


DATA 





005E 




SOSLTO 


BSS 


4 


0062 




SO$BTO 


BSS 


4 


0066 




SO$RFO 


BSS 


4 


006A 


0000 


ENDADD 


DATA 





006C 


0000 


ENDLIM 


DATA 





006E 


0000 


MEMSIZ 


DATA 





0070 


0000 


BASADJ 


DATA 





00^2 


0000 


TMTOL 


DATA 





00 7 4 


0000 




DATA 





00^6 




TMSDOR 


BSS 


4 


OO^A 




TM$OPN 


BSS 


4 



PTR TO Q1^ S rn A r 



BLOCKS 



SYSTEM LOG QUEUE IMG ROUTINE 
SCI BACKGROUND LIMIT 
SCI FOREGROUND LIMIT 
SCHEDULER MAP PILE POINTER 
BLOCK OP CURRENT DATE AND TIME 
ADDRESS OP MEM MGR HEADER 
ADDRESS OP SYS AREA HEADER 
SUBROUTINE TO KILL I/O - WP 
SUBROUTINE TO KILL I/O - PC 
CURRENT MAP PILE POINTER 
SYSTEM OVERLAY AREA 
LOAD OVERLAY OUEUE 
LINK TO OVERLAY 
BRANCH TO OVERLAY 
RETURN PROM OVERLAY 
LOAD ADR FOR FIRST USER TASK 
LIMIT REG FOR ENDADD 
SIZE OF MEMORY IN BEETS 
ADJUSTMENT VALUE FOR BIAS REG 
START OF TIME ORDER LIST 

SERIAL ACCESS DOOR LOCKING 

SERIAL ACCESS DOOR UNLOCKING 
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007E 




BM$FLS 


BSS 


A 


0082 


0000 


TMSEX" 1 


DATA 





0084 




PUSH1 


BSS 


4 


0088 




PUSH2 


BSS 


4 


0080 




PUSH3 


BSS 


4 


0090 




PUSH4 


BSS 


4 


0094 




PUSH 1 ^ 


BSS 


A 


0098 




PUSH6 


BSS 


4 


009C 




PUSH7 


BSS 


A 


00A0 




PUSH8 


BSS 


4 


00A4 




PUSH9 


BSS 


A 


00A8 




POPO 


BSS 


4 


OOAC 






BSS 


4 


00B0 




P0P2 


BSS 


4 


00B4 




P0P3 


BSS 


4 


00B8 




PQP4 


BSS 


4 


OOBC 




POP'S 


BSS 


4 


OOCO 




P0P6 


BSS 


4 


00C4 




P0P7 


BSS 


4 


00C8 




P0P8 


BSS 


4 


OOCC 




POPQ 


BSS 


4 


OODO 




MMSRUA 


BSS 


4 


00D4 




MM*GSA 


BSS 


4 


00D8 




MM$RSA 


BSS 


4 


OODC 




MM$GUA 


BSS 


4 


OOEO 




SCRASH 


BSS 


4 


00E4 




TMQUE 


BSS 


4 


00E8 




TMDQUE 


BSS 


4 


OOEC 




TMAQUE 


BSS 


4 


OOEO 


0000 


QHEAD 


DATA 





00F2 


0000 


STUNIT 


DATA 





00F4 


0000 


FLG12 


DATA 





00F6 


0000 


FLGWCS 


DATA 





00P8 




RETRID 


BSS 


4 


OOEC 




FMOPEN 


BSS 


4 


0100 




FMCLOS 


BSS 


4 


0104 




FMWRIT 


BSS 


4 


0108 




WRTSEQ 


BSS 


4 


01 OC 




CKWRIT 


BSS 


4 


0110 




CKLOCK 


BSS 


4 


01 14 




MAPREC 


BSS 


4 


0118 




UPDFDR 


BSS 


4 


01 1 c 




BMSMAP 


BSS 


4 


0120 




BM$RD 


BSS 


4 


0124 




BMSREL 


BSS 


4 


0128 


0000 


UAHADD 


DATA 





01 2A 


0000 


ENDDXL 


DATA 





01 2C 


0000 


MEMSW 


DATA 





01 2E 


0000 


DIOPDT 


DATA 





0130 


0000 


TLDTSB 


DATA 





0132 


0000 




DATA 





0134 


0000 


BIDTSB 


DATA 





0136 


0000 


TOLBET 


DATA 





0138 


0000 


OF#FCB 


DATA 
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BUFFER MGM^ FLUSH ROUTINE 

INFINITE EXTEND TIME SLICE 

SAVE REG R1 

SAVE REGISTERS R1 -R2 

SAVE REGISTERS R1 -R3 

SAVE REGISTERS R1-R4 

SAVE REGISTERS R1 _RR 

SAVE REGISTERS R1-R6 

ijRvu nxjVTio.ij'jno it i — n < 

SAVE REGISTERS R1-RR 

SAVE REGISTERS R1-RQ 

EXIT ROUTINE 

RESTORE R1 

RESTORE REGISTERS R1 -R2 

RESTORE REGISTERS R1 -R3 

RESTORE REGISTERS R1 -R4 

RESTORE REGISTERS R1-R5 

RESTORE REGISTERS R1-R6 

RESTORE REGISTERS R1-R7 

RESTORE REGISTERS R1-R8 

RESTORE REGISTERS R1 -RQ 

RETURN USER AREA MEMORY 

GET SYSTEM AREA 

RETURN SYSTEM AREA 

GET USER AREA 

SYSTEM CRASH ROUTINE 

GENERAL QUEUEING ROUTINE 

GENERAL DEOUEUEING ROUTINE 

QUEUE ON ACTIVE QUEUE 

ADDR OF SVC QUEUES 

CLOCK TICKS / SYSTEM TIME UNIT 

MACHINE FLAG Q=/10,-1=/12 (VAL) 

WCS FLAG 0=NO; 1 =YES - f VALUE) 

RETURN RUN TIME ID 

FMT FILE OPEN PROCESSOR 

FMT FILE CLOSE PROCESSOR 

FMT FILE WRITE PROCESSOR 

SEQUENTIAL FILE WRITE 

CHECK WRITE ACCESS 

CHECK IF RECORD LOCKED 

TRANSLATE BLOCK # TO ADU # 

UPDATE FILE DESCRIPTOR RECORD 

MAP IN TASK BUFFER 

RETRIVE FILE BLOCK 

RELEASE FILE BLOCK 

BEET ADDRESS OF UAHEAD 

LIMIT 1 REG VALUE FOR DX-1 

USER MEMORY SIZE SWITCH 

ADDRESS OF DISC PDT 

TSB FOR TASK LOADER 

* * * RESERVED * * * 

TSB FOR BID TASK 

FIRST BEET time ORDERED 

FCB ADDRESS OF OVERLAY 
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01 ^A 


0000 


RFSFCB 


DATA 





013C 


0000 


OF$LDT 


DATA 





01 3E 


0000 


PF1LDT 


DATA 





0140 


0000 


PF2LDT 


DATA 





0142 


0000 


PF3LDT 


DATA 





0144 


0000 


RF$LDT 


DATA 





0146 


0000 


SCRSHD 


DATA 





0148 


0000 


SCR$TK 


DATA 





01 4A 


0000 


SCR$SC 


DATA 





014C 


0000 


SCRSDA 


DATA 





01 4E 


0000 


TOLLNK 


DATA 





0150 


0000 


RIDMAP 


DATA 





0152 


0000 


CMEMSZ 


DATA 





0154 


0000 


SCNPDT 


DATA 





0156 


0000 


SYSPFN 


DATA 





0158 


0000 


SCRSSL 


DATA 





01 5A 


0000 


XY 


DATA 





015C 


0000 


UNLPDT 


DATA 





01 5E 


0000 


SCHDWS 


DATA 





0160 


0000 


SLCSUS 


DATA 





0162 


0000 


BMSSIZ 


DATA 





0164 


0000 


MMUMAX 


DATA 





0166 




FMSRDM 


BSS 


4 


01 6A 




BM$MP2 


BSS 


4 


01 6E 




TM#INC 


BSS 


4 


0172 




TM$DEC 


BSS 


4 


01 ^6 




TM$CLR 


BSS 


4 


01 7A 


0000 


S$$PAT 


DATA 





01 7C 


0000 


CTRYCD 


DATA 





01 7E 


0000 


TM$TO 


DATA 





0180 


0000 


MMSPAK 


DATA 





OIN 










0000 


0182 


0VTST7, 


EQU 
RORCx 


$ 



ROLL PILE FOB 

OVERLAY FILE LDT 

LDT FOR LUNO D 

LDT FOR LUNO B 

LDT FOR LUNO F 

ROLL FILE LDT 

HEAD ADR CRASH FILE 

CYLINDER ADR CRASH 

SECTOR ADR CRASH FILE 

TILINE ADR CRASH FILE 

TOL LINKAGE ROUTINE 

ADR RUN TIME ID BIT MAP 

MEMORY TO BE CRASH DUMPED 

DSR POWER UP ROUTINES 

NAME OF SYSTEM PROGRAM FILE 

CRASH FILE UNIT SELECT 

TRAP INITIALIZATION ^ABLE 

UNLOAD PD^ CURRENTLY IN USE 

SCHEDULER WORKSPACE 

SCHEDULER ENTRY POINT 

LENCr m H OF MEM RESIDENT BUFFER 

MAXIMUM SIZE FREE USER AREA 

READ MULTIPLE 

CHECK MEMORY PROTECTION 

INCREMENT TM^EXT BLWP VECTOR 

DECREMENT TMSEXT BLWP VECTOR 

CLEAR TM$EXT BLWP VECTOR 

BEGINNING OF PATCH AREA 

COUNTRY CODE 

POINTER TO TM$TO 

MEMORY t>ACK REQUEST FLAG CNOT A 
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6.12 MEMORY MANAGEMENT LISTS 

In addition to the time ordered list (TOL), which is a list of all 
allocated blocks of user memory (as opposed to system table areal , two 
free memory lists are maintained by memory management. 

One is a list of free blocks of system table area and is headed by the 
SAHEAD anchor in the D$DATA module. The list is singly linked" and 
ordered by increasing address of the free block. Each free block 
contains the following overhead in the first four bytes: 

Bytes Description 



0-1 Size of block in bytes 
2-3 Link to the next block 

When a block of system table area is allocated, the size of the block 
is stored in the word immediately preceding the first word of the 
allocated block (i.e., negative offset). 

The other list contains free user memory blocks, and is headed by the 
UAHEAD anchor in the D$DATA module. The list is also singly linked and 
ordered by increasing address. Each block contains an overhead beet as 
described in paragraph 6 . 8 on the Time Ordered List (TOL). 



6.13 STRUCTURE OP THE SEQUENTIAL PILE CREATED BY BACKUP DIRECTORY 

By using the Backup Directory command, a directory can be backed up to 
a sequential file. The following are two examples of the structures of 
the sequential files created by backing up the directory of Pigure 6-^n 
while using the control file of Pigure 6-^1 . 

Pigure 6-^2 shows the expanded structure of the backup of a program 
file. In Release ?."*, the block option was introduced. The block 
option causes information to be blocked in physical records o^ 9600 
bytes (this may be altered in the Backup Directory PROC). The records 
are packed by preceding eachlogical record by a character count. An 
EOP fend of file) is represented by a zero count. The first record 
(the label) is not packed. The backup directory is still terminated by 
two physical EOPs when blocking is selected. Also, the tape label is 
extended from n words to 15 words. 
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SRC 



VCATALOG 



UT 



GLEN 



ANNA 



OBJ 



0©00 



LST 



SRC 



ALIASES 

CI FOR C 
B1 FOR B 
A1 FOR B 
A 2 FOR A 



OBJ 



LST 



©00©© ©0©©0©0©© 



OBJ 2 



(nev\m ( OLD ) 



2278137 



Figure 6-^0 Directory ^o Be Backed Up 
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MOVE 


.UT. GLEN. SRC, 


.SEQFILE 


EXCLUDE 


B 




MOVE 


.UT. GLEN. OBJ 




EXCLUDE 


B 




MOVE 


•UT.GLEN.LST 




EXCLUDE 
MOVE 


B 
.UT.ANNA 




TTlXTT-k 

EjLVU 







Figure 6-31 Control File 



FDR S$PROGA 



DATA S$PROGA 



\ 



\ 



N, 



INSTALL SVC FOR A 



MODULE A 



INSTALL SVC FOR B 



MODULE B 



2278138 



Figure 6-32 Expanded Structure for a Program File 



6.13.1 BACKUP DIRECTORY WITH NOMULTI OPTION SELECTED. 

Figure 6-32 represents the format of a tape created by the Backup 
Directory utility with the NOMULTI option specified. The MULTI/NOMULTI 
option was available on Release 3.2 and earlier. Later releases use 
the MULTI format exclusively. The only difference between the two 
formats is a header used by the MULTI format that begins every volume. 

The first record written is the directory overhead record (DOR) of the 
first directory. Following the DOR are the FDRs and data records of 
the files under the directory. The end of the directory is noted by an 
EOD marker. The EOD marker is a record consisting of the following 
four bytes: EODb where b equals a blank space. 
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DOR OF .UT. GLEN. SRC 



FDR OF A 



DATA OF A 



WWWWeqfWWW^ 



FDR OF C 



kWWWWWWWW 



DATA OF C 



^ 



EOD MARKER 



DOR OF .UT. GLEN. OB J 



FDR OF A 



V\\\\\\\ EOF \\\\\\^ 



2278139 (1/5) 



DATA OF A 



FDR OF 0BJ2 



FDR OF NEW 



DATA OF NEW 



Figure 6-T? Structure of .SEQFILE fSheet 1 of ^ 
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KWWWWeofWWWW^ 

\\\\\\\\\ \\\\\\N \ 



DATA OF C 

KWWWWeqfWWWWM 



2278139 (2/5) 



FDR OF OLD 



DATA OF OLD 



EOD MARKER 



FDR OF C 



EOD MARKER 



DOR OF .UT.GLEN.LST 



FDR OF A 



DATA OF A 



\\\\\\\\\eof\\\\\\W\ 



ADR OF Al 



ADR OF A2 



Figure 6-"^ Structure of .SEOPILE (Sheet 2 of 5) 
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FDR OF C 



DATA OF C 



vWWWWqfWWY 



ADR OF CI 



EOD MARKER 



DOR OF. UT. ANNA 



FDR OF SRC 



FDR OF X 



WWWW EOF \\\\\\^ 



DATA OF X 



FDR OF Y 



DATA OF Y 



\\VA\W EOF \\\\\\^ 



2278139 (3/5) 



FDR OF Z 



Figure 6-?"? Structure of . SEQFILE ( Sheet ^ of 5) 
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\\\\\\\\\Eor\\\\\\^ 



DATA OF Z 



EOD MARKER 



FDR OF OBJ 



DFR OF X 



DATA OF X 



\\\\\\\\\eof\\\\\^ 



FDR OF Y 



AWWWVqf \WW\W 



DATA OF Y 



DFR OF Z 



DATA OF Z 



WWWW EOF www^ 



(. 2278139 (4/5) 



EOD MARKER 



FDR OF LST 



Figure 6-^ Structure of . SEQFILE ( Sheet 4 of 5) 
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FDR OF X 



DATA OF X 



A\WW\E0F\\\\\\^ 



FDR OF Y 



WWWW EOF \\\\\^ 



DATA OF Y 



FDR OF Z 



DATA OF Z 



\\\\\\\\ EOF \\\\\^ 



2278139 (5/5) 



EOD MARKER 



EOD MARKER 



EOF 



EOF 



NOTE 

An EOD marker is a record with EODb in the first 
four "bytes, where b equals a "blank space. 



Figure 6-^ Structure of .SEQEILE 'Sheet 5 of 5) 
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6.13.2 Backup Directory with MULTI Option Specified 

The MULTI option is specified when a directory is being backed up 
magnetic tape and the directory spans more than one tape volume. 



to 



If the MULTI option is specified, the first record written to the 
sequential file is a header record (see tape 1, Figure 6-34) . The 
header record consists of the following words: 



Word 



Contents 



1-3 The ASCII characters **HDR* 

4-7 Date and time as returned from SVC call 

8 Tape volume number 

9 Blocking factor 
10-15 Reserved 



After the header 
NOMULTI file. 



record, the file has the same structures as the 



When the end of tape is encountered by Backup Directory, the record 
being written to tape is saved to be written to the next tape. After 
the tape has been changed, a header record is written to the new tape 
(see Tape 2, Figure 6-34), The header record has the same format as 
the header record of the first tape, except that the volume has been 
incremented by 1. The date and time written will be the same as that 
of the first tape. The record being written when the end of tape was 
encountered is then written and the backup continues. 
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TAPE 1 



MULTI VOLUME HEADER 
* * HDR * 
DATE 
VOL 1 




DOR OF .UT. GLEN. SRC 




FDR OF A 




• 
• 
• 




DOR OF .UT.ANNA 


FDR OF SRC 




FDR OF X 




DATA OF X 


« 



END OF TAPE 



2278140 



TAPE 2 



wwww ~ wvw^ 



MULTI VOLUME HEADER 
**HDR* .DATA, VOL 2 



CONTINUATION OF 
DATA OF X 



FDR OF Y 



DATA OF Z 



\WW\W^WW\W? 



EOD MARKER 



EOD MARKER 



\\\\\\\ - WWWT 



AWWW - WOftSX 



<| END OF DIRECTORY 



Figure 6-^A Back-up Directory ^ape Format 
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SECTION 7 
DX10 DATA BASE MODULES 



7 . 1 GENERAL 

Part of the memory resident DXIO kernel consists of the two DX10 
data base modules, DSDATA and DXDAT2. The data base is split into two 
modules in order to separate sysgen dependent data from static data. 
Constant data is contained in~DXDAT2. The D$DATA module is built by 
GEN990, and contains all of the sysgen dependent data. The following 
paragraphs describe the contents of the two data modules. 



7.2 D$DATA 

The D$DATA template is in file .DXMISC . SOURCE. D$DATA on the source 
disk. The first section of this module contains system constants 
(e.g., time slice, size of the system table area), list headers, and 
pointers (e.g., ETSK, which pointsto the task status block of the 
currently executing task), and a table of user defined SVCs. 

The next section of D$DATA contains task status blocks for a file 
management task (EM$TSK) for each disk drive and the task bidder 
(TMSBID) . 

A keyboard status block table follows the TSBs. Each entry in the 
table points to the KSB for the station whose ID corresponds to the 
table index (i.e., first table entry points to KSB for ST01 , third 
entry points to KSB for ST03, etc.). 

The next section of the DSDATA module contains the PDT for every device 
defined in the system, including the KSBs for all terminals. 

Following the PDTs are the global LDTs . There is a global LUNO 
(represented by a logical device table) assigned to every disk drive, 
and one assigned to ST01 . 

The remainder of the DSDATA module contains system log data, the system 
table area, the breakpoint table, the system overlay areas, the 
interrupt and XOP trap initialization table (written to locations >00- 
>7P by the DX10 image loader), and the interrupt decoding module. 
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7.5 DXDAT2 

The DXDAT2 source module is on the file named 
.DXMISC. SOURCE. DXDAT2 on the source disk. The constant data base 
module contains system SVC information, queue anchors for most system 
queues, and TSBs for some link-in system tasks. 

The first section of this module is a table of constants which are 
often used by DX10 routines. The next section is a vector table of SVC 
processor addresses, and is used by the SVC interpreting code. 
Following the vector table is a table of the lengths of all supervisor 
call blocks. This table is used by this SVC intepreter, to find out 
how much call block needs to be buffered before passing control to the 
SVC processor. 

The next section contains the anchors for most of the DX10 queues. 
Each anchor is of the form described in the data structures section. 

Following the queue anchors is the list of SVC definition blocks which 
are used by the SVC unbuffering task, SVCCLN, to decide what 
information needs to be returned (unbuffered) to a task which has 
issued an SVC processed by a queue server. The list is terminated by a 
zero word. 

The next section of DXDAT2 is a list of return field definitions, which 
is used by SVCCLN to determine which fields within a buffered 
supervisor call block need to be unbuffered into the calling task. 
This list is also ended by a zero word. 

The next section contains task status blocks for the following linked- 
in system tasks: 

* Task loader (TM&LDR) 

* Overlay loader (TM$0VY) 

* Buffer read/write task (TM$RWT) 

* Device driver task (DDT) 

* Disk manager (DM$TSK) 

* SVC clean up task (SVCCLN) 

* System overlay loader (SOVLDR). 

The remainder of the DXDAT2 module contains the workspace used by the 
scheduler to update the time and date. 
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Section 8 
COMMON SYSTEM ROUTINES 



8.1 STACKING ROUTINES 

Routines in DX10 use runtime stacks for passing parameters, storing 
registers and return information, and loading registers. In order to 
allow several routines that share a common workspace to use the same 
stack, RIO is reserved in DX10 routines as a pointer to the top of the I 
stack (next available entry) . Several stack handling routines, PUSHn I 
and POPn, are used to store data on, and retrieve data from, a stack. 

PUSHn is used to store registers Rl-Rn (n </= 9) on the stack. PUSH 
automatically increments the stack pointer, RIO, to point to the top of 
the stack, To call PUSH, execute a BL to @PUSHn. For example: 

BL @PUSH3 STORE R3, R2 , Rl 

or 
BL @PUSH9 STORE REGISTERS 9-1 

PUSH stores the registers starting with the highest numbered register 
(i.e. a call to PUSH3 will store R3 first, then R2, and finally Rl) , 
and always clear RO. 

Before calling PUSH, a routine must store its return address (usually I 
the value of Rll, if the routine was called via a BL instruction) on 
the stack. The example at the end of this description shows the 
general DX10 convention for using PUSH. 

POPn is used to load registers Rl-Rn from the top n words of the stack 
(n </= 9) and to return from a subroutine. POPn automatically 
decrements the stack pointer, RIO, to point to the new top of the 
stack. Registers are loaded starting with Rl. POP is entered by 
executing a B instruction to POPn. 

POPO is a special entry point into POP, and is always executed at the 
end of any call to POP. POPO loads Rll with the top word of the stack. 
This should contain the address of the word following the instruction 
which branched to the routine now using POP. If RO is zero (i.e. 
there are no errors being returned by the routine) , control returns to 
the word following the address in Rll. if RO is non-zero (error 
condition) but the value of the word addressed in Rll is zero (no error 
return address) , control also returns to the word following the address 
in Rll. If RO and the word addressed by Rll are both non-zero, control 
returns to the address contained in the word pointed to by Rll. 
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A conventional call to a subroutine which uses PUSH and POP is: 



BL 

DATA 

EQU 



@SUBR 
ERROR 
$ 



Call to subroutine 
Error return address 
Normal return point 



NORML 

The following example shows such a subroutine call 

REF PUSH5 , P0P5 
COPY .SYSTEM. TABLES. ORS 
* 

* OFFSETS FOR REGISTER STACK 
* 



EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
BSS 



0R1 

0R2 

0R3 

0R4 

0R5 

0R6 

0R7 

0R8 

0R9 

STACK 

* 

ws 

* 

*THIS IS THE MAIN PROGRAM 

MAIN LI RIO, STACK 

* 

* 
* 



-2 

-4 

-6 

-8 

-10 

-12 

-14 

-16 

-18 

30*2 



BSS 16*2 



NORML 
* 



BL @SUBR 
DATA ERROR 
EQU $ 



CREATE A 30 -WORD STACK 
CREATE A WORKSPACE 

INITIALIZE STACK POINTER, RIO 



CALL SUBROUTINE 

THIS IS THE ERROR RETURN ADDRESS 

THIS IS THE NORMAL RETURN 



ERROR 
* 

* 



RT 
EQU 



RETURN TO THE CALLING PROGRAM 



*THIS IS THE SUBROUTINE 
SUBR MOV R11,*R10+ 
BL @PUSH5 



STORE THE RETURN ADDRESS ON THE STACK 
STORE R1-R5, CLEAR R0 



EXAMPL 
* 


EQU 
MOV 
B 


$ 
§RVAL,@OR2(R10) 

@POP5 


SUBERR 


EQU 
LI 
B 
END 


$ 

R0,ERRCOD 

@POP5 



NORMAL EXIT 

STORE A RETURN VALUE IN THE STACKED R2 

RESTORE R1-R5, RETURN TO MAIN 

ERROR EXIT 

PUT ERROR CODE IN R0 

RESTORE R1-R5, TAKE ERROR RET IN MAIN 
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Elements of a stack may be accessed without using PUSH and POP, by 
using offsets into the stack indexed by the stack pointer, RIO, (as in 
EXAMPL above). The top word on the stack is at address §-2 (RIO), the 
next word is at @-4(R10), and so on down into the stack. Offsets for 
registers pushed onto a stack are given in .SYSTEM. TABLES. ORS. 



8 2 nrn?TT-nar! potthitvitpq 

There are six routines used within DX10 to add or delete entries from 
the various data queues. The routines are memory resident, and are 
located in the module TM$QUE. The routines are: TMAQUE, TMAQO, TMQUE, 
TMDQUE, TMTSBQ, and TM$QRM. These routines may be entered by memory 
resident system tasks by executing a BL to the name of the routine. 
Input register and stack requirements are given for each routine in the 
following paragraphs. Disk resident system tasks may access all of the 
routines except TMAQO via the system overlay table. 

8.2.1 TMQUE 

This is the general queueing routine. It places the specified data 
structure (any type) on the specified queue. The address of the 
structure to be queued is expected to be in R2. The address of the 
queue anchor should be in Rl. TMQUE requires from 6 to 24 words of 
stack, according to the following conditions: 

1. The queue has no dedicated server task — 6 words. 

2. The queue has a dedicated, memory resident server task — 12 
words. 

3. The queue has dedicated, disk resident server task — 24 words. 

When the data structure is placed on the queue, TMQUE checks two 
conditions. If the queue has a dedicated server task, and the task is 
terminated, TMQUE bids the task (calls TMBIDO) . If the queue server is 
in memory in - state >24, it is activated directly. If the queue is a 
TSB queue (entries are TSBs) , then the TSB that has just been queued is 
given the task state contained in the queue anchor (see paragraph 6.2 
on queues) . 

8.2.2 TMAQUE 

This routine puts the specified TSB on the active queue for that task's 
priority. TMAQUE uses six words of a stack. The routine expects Rl to 
contain the address of the TSB to be queued. The TSB flags are checked 
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to determine if the task has been allocated memory. If it does not 
have memory, TMAQUE calls TMAQU to put the task on the waiting on 
memory queue, TMWOM. If the task already has memory, TMAQUE checks the 
TSB priority, and calls TMQUE to put the task on the active queue for 
that priority. 



8.2.3 TMAQO 

This routine puts the specified TSB on the active queue at position one 
for priority one tasks. The task loader and the system overlay loader 
use TMAQO so that tasks which have just been loaded will get a good 
chance of executing at least once before being rolled. 



TMAQO uses six words of stack. The routine expects Rl to 
TSB address of the task to be queued. 



contain the 



8.2.4 TMTSBQ 

This routine queues the specified TSB on the specified queue. TMTSBQ 
is actually a second entry point to TMQUE, and is therefore the same 
routine. 

8.2.5 TMDQUE 

This is the general dequeuing routine. It is used to remove an entry 
from the head of the specified queue. The routine uses one word of a 
stack. The address of the dequeued anchor should be in Rl. TMDQUE 
will return the address of the dequeued data structure in R12, or an 
error message in RO. The only error code is 1, which means the queue 
is empty. 

8.2.6 TM$QRM 

This routine is used to remove any specified entry from the specified 
queue. It requires one word of a stack. The address of the queue 
anchor should be in Rl, and the address of the structure to be removed 
from the queue should be in R2. TM$QRM searches through the queue for 
an entry with the address specified in R2. If no such entry is in the 
queue, an error code of 1 is returned in RO. Otherwise, the structure 
is removed from the queue. 
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SECTION Q 
DESCRIPTION OP DX1 ROUTINES 



9 . 1 GENERAL 

This Rpptl OH "hT*«oplra -hVio mpnr*T» TIY1 H T»riii + i^po -iv\-hr* -PnviA+i ov^nl ^P + prrn^ 1 ' oq 

(e.g., task management, file management) and describes each routine 
briefly. Several tables are included which show how the routine source 
may be found on a DX10 source disk. 



9.2 SVC PROCESSING 

SVC processing includes individual SVC processing routines and several 
overhead routines that are involved in decoding SVCs and buffering and 
unbuffering supervisor call blocks. Tables 9-1 and 9-2 show the 
routines that process SVCs. 
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Routine 
SVC INT 



Table 9-1 SVC Overhead Routines 
Source Module Pathname Description 



DXMISC . SOURCE . SVC INT 



SVCBUP 



DXMISC . SOURCE . SVCBUP 



SVC END 



SVUBUP 



SVCCLN 



DXMISC . SOURCE . SVCBUE 



DXMISC . SOURCE . SVCBUP 



DXMISC . SOURCE . SVCCLN 



Interprets XOP 15 "by accessing user 
call block and SVC code. Looks up 
SVC processor address in SCTAB 
(DXDAT2 module), transfers control 
to that address. 

Buffers user call blocks for SVCs 
processed by queue serving tasks 
into system table area. Calls 
TMQUE to queue the buffered call 
block and bid the queue server. 

Looks up the SVC definition block 
in the DXDAT2 table, SVCDEE. 
Called by SVCBUP. 

Buffers the user's call block and 
any expansion blocks (as defined in 
the definition block retrieved by 
SVCPND) into system table area. 

Unbuffers the buffered call block 
after a queue serving SVC processor 
has finished. SVCCLN may have to 
cause the task to be rolled-in. 
The task is reactivated after the 
unbuff ering. The buffer is 
released to the system table area. 
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Table 9-2 


I SVC Processors — 


Part 1 of 2 


SVC 


SVC 


XOP/Queue 


Processor 


Source Module 


Code 


Title 
I/O 


Server 
X 


Name 
DXIOS 


Pathname 


00 


. DXMISC . SOURCE . DXIOS 


01 


Wait for I/O 


X 


WAITIO 


.DXMISC. SOURCE. WAITIO 


02 


Time delay- 


X 


TDLY 


. TSKMGR . SOURCE . TMSFUN 


03 


Date and time 


X 


DTTIM 


. TSKMGR . SOURCE . TMSFUN 


04 


End of task 


Q 


ENDTSK 


. TSKMGR. SOURCE. TMSFUN 


05 


Bid task 


Q 


TM$SBD 


. SYSTSK. SOURCE . TMSSBD 


06 


Unconditional wait 


X 


UNCDWT 


. TSKMGR . SOURCE . TM$EUN 


07 


Activate suspended 
task 


X 


ACTTSK 


. TSKMGR. SOURCE. TM$FUN 


09 


Do not suspend 


X 


HOTSK 


. TSKMGR . SOURCE . TM$FUN 


OA 


Convert binary to 
decimal 


X 


CBDA 


. DXMI SC . SOURCE . CNVRSN 


OB 


Convert decimal to 
binary 


X 


CDAB 


. DXMISC . SOURCE . CNVRSN 


OC 


Convert binary to 
hexadecimal 


X 


CBHA 


. DXMISC . SOURCE . CNVRSN 


OD 


Convert hexadecimal 
to binary 


X 


CHAB 


. DXMISC . SOURCE . CNVRSN 


OE 


Activate time delay 
task 


X 


ATDLYT 


. TSKMGR . SOURCE . TMSFUN 


OP 


Abort I/O (LUNO) 


X 


ABTIOX 


.DXMISC. SOURCE. ABTIOX 


10 


Get common data • 
address 


X 


GETCOM 


. TSKMGR . SOURCE . TMSCMN 


11 


Change priority 


X 


CHGPRI 


. T SKMGR . SOURCE . TM$EUN 


12 


Get memory 


Q 


MMSGTM 


. MEMMGR . SOURCE . MMSSVC 


13 


Release memory 


X 


MMSRTM 


. MEMMGR . SOURCE . MMSSVC 


14 


Load overlay 


Q 


TMSOVY 


. TSKMGR . SOURCE . TM$OVY 


15 


Disk file utility 


Q 


FUTIL 


.EUTIL. SOURCE. EU$ 


16 


End of program 


Q 


ENDPGM 


. TSKMGR . SOURCE . TMSEUN 


17 


Get parameters 


X 


GETPRM 


. TSKMGR . SOURCE . TMSFUN 


1B 


Return common data 


X 


RETCOM 


. TSKMGR . SOURCE . TMSCMN 


1C 


Put data 


X 


PUTDAT 


. TSKMGR . SOURCE . TM&IQ 


1D 


Get data 


X 


GETDAT 


. TSKMGR . SOURCE . TMSIQ 


1F 


Scheduled bid task 


Q 


TMSSBD 


. SYSTSK . SOURCE . TMSSBD 


20 


Install disk volume 


Q 


INSTAL 


. SYSTSK. SOURCE . INSTAL 


21 


System log SVC 


Q 


SLSVC 


. SYSTSK. SOURCE. SYSLGY 


22 


Disk manager 


Q 


DMSTSK 


. DSCMGR . SOURCE . DMSTSK 


24 


Suspend awaiting 
queue input 


X 


SUSPQI 


. TSKMGR . SOURCE . TMSFUN 


25 


Install task 


Q 


PFSLIN 


(SYSTEM TASK) 


26 


Install procedure 


Q 


PFSLIN 




27 


Install overlay 


Q 


PESLIN 




28 


Delete task 


Q 


PFSLDE 


(SYSTEM TASK) 


29 


Delete procedure 


Q 


PESLDE 




2A 


Delete overlay 


Q 


PESLDE 




2B 


Execute task 


Q 


EXCTSK 


. TSKMGR . SOURCE . TMSEUN 


2C 


Read/write TSB 


X 


TSMWRT 


. TSKMGR. SOURCE. TMSRWT 


^D 


Read/write task 


Q 


TM$WRT 


. T SKMGR . SOURCE . TM$RWT 


^E 


Self identification 


X 


TMSSID 


. TSKMGR. SOURCE. TMSEUN 
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Table 9-2 SVC Processors — Part 2 of 2 



SVC 


svc xo: 


P/Queue 


Processor 


Code 


Title Server 


Name 


2F 


End action status 


X 


TMSEAS 


30 


(Jet event character 


X 


GTEVNT 


31 


Map program name 
to ID 


Q 


PF$LMN 


32 


Get overlay table 
address 


X 


GTOVYT 


33 


Kill task SVC 


Q 


SVCKIL 


34 


Unload disk volume 


Q 


INSTAL 


35 


Poll status of task 
in terminal task set 


X 


TMSST 


36 


Wait on multiple 
initiate i/Os 


X 


WANYIO 


37 


Assign space on 
program file 


Q 


PF$LAS 


38 


Initialize disk 
volume 


Q 


INVOL 


39 


Get event character 


X 


GTEVTL 


3B 


Initialize date 
and time 


X 


SDTIM 


3E 


Reset end action 


X 


RSTEAC 


3F 


Retrieve system data 


X 





Source Module 
Pathname 

. TSKMGR . SOURCE . TM$EAS 
. DXI . SOURCE . GETEVT 
(SYSTEM TASK") 

. TSKMGR . SOURCE . TM$FUN 

. SYSTSK . SOURCE .SVCKIL 
. SYSTSK . SOURCE . INSTAL 
. TSKMGR . SOURCE . TM$FUN 

.DXMISC. SOURCE. WAITIO 

(SYSTEM TASK) 

. SYSTSK . SOURCE . INVOL 

.DIO. SOURCE. GETEVT 

. TSKMGR . SOURCE . TM$DTM 

. TSKMGR . SOURCE . TMSPUN 
. T SKMGR . SOURCE . TM$FUN 



9-3 BID TASK SUPERVISOR CALL - CODE >05 

The Bid Task supervisor call is included in DX10 3-4 for 
compatibility with DX10 2.X releases. Because this SVC may be deleted 
in later releases, use of the Bid Task SVC is not recommended. 
Documentation is included in this System Design Document for 
informative purposes. 

The Bid Task SVC can only be used for tasks that have been 
installed on the single system program file and that were designated as 
being non-replicatable. The call is tranmitted to an Execute Task 
(>2B) SVC by the operating system task TMSBD. The task is bid with no 
associated station, and the calling task is not suspended. 

The call block for the Bid Task supervisor call is eight bytes in 
length and must be aligned on a word boundary. The entries in the 
supervisor call block are defined as follows: 



Byte 
Byte 1 
Byte 2 
Byte 3 



- Contains the code for the Bid Task supervisor call 
and must be >05« 

- This byte is used by the system to return an 
code, if necessary. 

- Contains the installed ID on the system program 
of the task to be executed. 

- Reserved. 



error 



file 
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Bytes 4- 7 - These "bytes are used to pass user specified 
parameters to the called task. The called task must 
issue a Get Parameters supervisor call to obtain the 
parameters. 

The following example of a Bid Task supervisor call specifies that 
task >5E be loaded from the system program file. The ASCII 
representation of the characters HELP are passed to the called task. 



JfiVJfiN 

BIDT BYTE >05 

ERRC BYTE >00 

ID BYTE >5E 

BYTE >00 

PARMS TEXT 'HELP 



FORCE ALIGNMENT ON A WORD BOUNDARY 

CODE FOR BID TASK 

SET BYTE ONE TO ZERO 

INSTALLED ID OP TASK TO BE EXECUTED 

RESERVED (SET TO ZERO) 

EOUR BYTES PASSED TO CALLED TASK 



Within the procedure portion of the calling task, the following 
statement is used to initiate the Bid Task supervisor call: 

XOP BIDT, 15 

Error codes returned in Byte 1 of the supervisor call block are as 
follows: 



Error Code 



MEANING 



>04 

>FF 



Other 



Signifies successful completion, 
compatibility with previous releases. 



for 



Either: specified task is not on the system 
program file; the specified task is on the system 
program file and is replicatale; or an error 
occurred when the translated Execute Task SVC was 
performed. 

A task state is returned. This is the task state 
of the called task if it is already in execution. 
Or if a currently running task has allocated the 
run ID corresponding to the called tasks 
installed ID, that tasks state is returned as an 
error code. 



9-4 TASK MANAGER 

The main routines involved in task management are the scheduler, 
task loader, overlay loader, system overlay loader, and the task 
managing SVCs. The task loader also works closely with memory 
management routines, which are discussed in the next paragraph. 
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Table 9-3 shows the major task management routines. 

Table 9-3 Task Management Routines — Part 1 of 4 
Routine Source Module Pathname Description 



TM$SHD 



TM$LDR 



TM$0VY 



TSKMGR . SOURCE . TMSSHD 



TSKMGR . SOURCE . TM$LDR 



TSKMGR . SOURCE . TMSOVY 



SOVLDR 



DXMISC . SOURCE . SOVLDR 



S0$LT0 



DXMISC . SOURCE . SOSCPR 



SOSBTO 



DXMISC . SOURCE. S0$CPR 



Task scheduler. Updates time and 

date, and delayed tasks, bids SCI, 

and selects the next task to 
execute. 

Task loader. Loads tasks and 
procedures, rolls out quieted tasks 
and tasks that have issued Get 
Memory SVCs. 

Overlay loader. Loads overlays 
requested by tasks. Requests are 
queued for the overlay loader, 
which loads the overlay and calls 
TMAQUE to put the task on an active 
queue. TM$0VY calls file 
management routines to read the 
overlay from disk. 

System overlay loader. Serves the 
queue SOVYQ. TSBs of tasks that 
have called system overlays are 
queued on SOVYQ. SOVLDR loads the 
correct overlay and reactivates the 
task, calling TMAQO. 

Link to system overlay. This 
routine is called by a task or 
overlay to link to a system 
overlay. If the desired overlay is 
in memory, the TSB is altered to 
link in the overlay; otherwise, the 
TSB is queued for SOVLDR and the 
task is suspended. 

Branch to system overlay. This 
routine is called by one system 
overlay to branch to • another 
overlay. If the desired overlay is 
already in memory the calling 
task's TSB is modified; otherwise, 
the TSB is queued for OVLDR and the 
task is suspended. 
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Routine 
S0$RF0 



Table 9-3 Task Management Routines — Part 2 of 4 
Source Module Pathname Description 



DXMISC . SOURCE. SOSCPR 



TM$D0R 



TSKMGR . SOURCE . TMSDOR 



TM$0PN 



TSKMGR. SOURCE. TM$OPN 



TM$CLK 



TRAPRT 



TSKMGR . SOURCE . TM$0 PN 



'SKMGR . SOURCE . TMSRTN 



X0PRT1 



TSKMGR . SOURCE . TMSRTN 



SCHRET 



TSKMGR . SOURCE . TMSRTN 



Relink from system overlay. This 
routine is* called by a system 
overlay to relink back to the last 
task or overlay that performed a 
link to overlay. If the relink is 
back to a task, or back to an 
overlay that is in memory, control 
is transferred immediately. If the 
relink is back to an overlay no 
longer in memory, the current task 
is suspended and the TSB is queued 
for SOVLDR. 

Enforce access privileges to door 
of a particular structure. The 
door is represented as a queue. If 
the data structure is being 
accessed by a task, the task 
wanting access is queued and 
suspended. Queued tasks will be 
unsuspended and gain access when 
the current accessing task exits 
the door, via TM$OPN. 

Open the door to a restricted 
access structure. This routine is 
called by a task to release access 
to the door. The next task in the 
queue is unsuspended and the door 
marked open. 

Clock interrupt handler. Resets 
the timer interrupt, updates the 
second counter, clock unit counter 
and time slice counter. 

Return point from all interrupt 
processors. Returns control to 
interrupted task (if its time slice 
has not expired), XOP, or other 
interrupt processor. 

First return from XOP processors. 
Returns control to the executing 
task if its time slice has not 
expired. Otherwise, it saves the 
state of the executing task and 
returns control the scheduler. 

Return to scheduler by force. 
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Table 9-3 Task Management Routines — Part 3 of 4 
Routine Source Module Pathname Description 



X0PRT2, 
X0PRT3 



TM$DPR 



TOLLNK 

TOLDEL 
TOLTDL 

TOLTLK 

TOLTSG 
TMALPR 



TMIMAG 



TSKMGR . SOURCE . TMRTN 
TSKMGR . SOURCE . TMRTN 



TSKMGR . SOURCE . TM$DPR 



TSKMGR . SOURCE . TM$TOL 



TSKMGR . SOURCE . TM$TOL 



TSKMGR . SOURCE. TM$T0L 



TSKMGR. SOURCE. TM$T0L 



TSKMGR . SOURCE . TMSTOL 



TSKMGR . SOURCE . TMALPR 



TSKMGR . SOURCE . TMIMAG 



Return points from XOP processors 
that want the calling task 
suspended. Task execution is 
halted and control returns to the 
scheduler. 

Dynamic task priority routine. 
This routine is called "by the 
device driver task to adjust the 
priority of a task installed with 
dynamic priority, according to the 
type of I/O it is performing. 

Link a block of memory onto the 
head of the time ordered list 
(TOL). 

Delink the specified block of 
memory from the time ordered list. 

Delink the task segment of the 
specified task from the TOL. 

Link the task segment of the 
specified task onto the head of the 
TOL. 

Calculate the beet address of the 
start of the task segment of the 
specified task. 

Allocate memory for a procedure. 
The procedure may be either in 
memory already, on a program file, 
or on the roll file. Called by the 
task loader. 

Load program segment from image 
file. Loads either a task or 
procedure from a program file or 
the roll file. Called by TMLDTK 
and TMLDPR. 
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Routine 
TMLDPR 

TMLDTK 

TMRDAL 



Table 9-3 Task Management Routines — ■ Part 4 of 4 
Source Module Pathname Description 



TSKMGR . SOURCE . TMLDPR 



TSKMGR . SOURCE . TMLDTK 



TSKMGR . SOURCE . TMRDAL 



TMRDDL 



RSET12 



TSKMGR . SOURCE . TMRDLL 



TSKMGR . SOURCE . TM$INT 



Load a procedure from disk, either 
from a program file or the roll 
file. Called "by task loader. 

Load a task segment from disk, 
either from a program file or the 
roll file. Called "by task loader. 

Allocate space of the roll file. 
The allocation information is set 
up in the TSB or PSB of the segment 
being rolled. The TSB or PSB is 
linked onto the roll directory 
list. Called by task loader and 
memory management . 

Delink the specified segment from 
the roll directory list. This 
causes the space occupied by the 
rolled segment to become available. 

Clears the Protection, Overflow, 
and WCS flags in the status 
register. This must be called 
whenever entering map from an INT 
or XOP. 
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9-5 MEMORY MANAGER 

Memory management routines perform such functions as allocating memory, 
releasing memory, and rolling out tasks, procedures and buffers. A 
special connection of routines, called "buffer management, allocates, 
deallocates, reads, and writes file I/O buffers. Table 9-4 shows the 
major memory management routines. Table 9-5 shows the buffer 
management routines, which are generally called by file management. 



Routine 
MMSGSA 



Table 9-4 Memory Management Routines — Part 1 of 2 
Source Module Pathname Description 



MEMMGR . SOURCE . MMSMGR 



MM$RSA 



MEMMGR . SOURCE . MMSMGR 



MM$GUA 



MEMMGR . SOURCE . MMSMGR 



MM$RUA 



MEMMGR . SOURCE . MMSMGR 



MM$GS0 



. MEMMGR . SOURCE . MMSMGR 



Get system table area. This 
routine searches the free system 
area list for a block of the 
specified length and allocates it, 
if possible. 

Release system table area. This 
routine releases the specified 
block of system area, placing it on 
the free list. The block is 
consolidated with neighboring 
blocks if possible. 

Get user area. This routine 
searches the free user memory (all 
memory beyond DX10) list for a 
block of the specified length and 
allocates it, if possible. 

Release user area. This routine 
links the specified block of user 
memory onto the free list and 
consolidates it with neighboring 
blocks, if possible. 

Get system table area, clear to 
zero. This routine calls MMSGSA, 
then clears the allocated block (if 
successful) to zero. 
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Table 9-4 Memory Management Routines — Part 2 of 2 
Routine Source Module Pathname Description 



MM$END 



MEMMGR . SOURCE . MM$FND 



MM$SCN 



MEMMGR . SOURCE . MMSSCN 



MM$R0L 



MEMMGR . SOURCE . MMSROL 



MMSRLM 



MEMMGR . SOURCE . MMSTSK 



RELPSB 
MM$TSB 



MEMMGR . SOURCE . MM$TSK 



MEMMGR . SOURCE . MM$T SK 



Find (user) memory. This routine 
is called "by all routines that need 
a block of user memory. Entry to 
the routine is restricted to serial 
access by the use of TM&DOR and 
TMSOPN. MM$PND first checks free 
memory, then scans the TOL for 
rollable blocks. If a rollable 
block is found, it is rolled. 

Scan the TOL for a rollable block. 
This routine is called by MM$END to 
get a rollable block of memory if 
there is not a large enough block 
of free memory. Rollable blocks 
may be task, procedure or buffer 
memory. 

Roll a task or procedure segment to 
the roll file. This routine rolls 
a block to disk, assuming that roll 
file space is already allocated. 
Calls BM$MAP and PM$WTM. 

Release task memory routine. This 
routine delinks the task memory of 
the specified task from the TOL and 
releases it. If there are attached 
procedures, their attached task 
counts are decremented. If the 
count for a procedure goes to zero, 
its memory and PSB are released. 



Release the specified 
procedure memory. 



PSB and 



Release TSB and memory of a task 
suspended awaiting queue input. 
This routine searches the TSB list 
for a suspended queue serving task. 
If one is found, the task's memory 
and TSB are released. 
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Routine 
BM$RD 



BM$NEW 



MEMMGR . SOURCE . BM$RD 



BM$CL0 



MEMMGR . SOURCE . BM$CLO 



BM$FLS 



BM$SCH 



BM$UPD 



Table 9-5 Buffer Management Routines — Part 1 of 3 

Source Module Pathname Description 

.MEMGR. SOURCE. BM$RD Find a particular file blocking 

buffer (a file physical record) and 
map it into the calling task 
(usually file management) . If the 
buffer is in memory, delink it from 
the TOL and map it in. Otherwise, 
allocate memory and read in the 
correct file physical record, then 
map it in. 

Same as BM$RD except that it will 
not read in a file record. BM$NEW 
is used to avoid reading a 
sequential file record when 
preparing to write it. 

Close file. This routine writes 
all modified blocks of the file for 
a given LUNO (LDT) that are still 
in memory. The blocks remain on 
the TOL until needed by MM&FND. 

Flush blocks. This routine returns 
all memory occupied by buffers for 
the specified file. Modified 
buffers are written to the file 
before being released. Memory 
resident buffers are marked empty 
and left on the TOL. 

Search for a particular buffer on 

the TOL. THe search can be 

restricted by the following buffer 
criteria: 

. . . Modified or unmodified buffer 
with equal LDT address. 

. . . Modified buffer with equal 
LDT address. 

. . . Modified buffer with equal 
FCB address. 

Update file. This routine calls 
BM$SCH to find a buffer on the TOL 
according to the desired criteria. 
If the buffer is modified, it is 
written to the file. 



MEMMGR . SOURCE . BM$CL0 



MEMMGR . SOURCE . BM$CLO 



. MEMMGR . SOURCE . BMSCLO 
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Table 9-5 Buffer Management Routines — Part 2 of 3 
Routine Source Module Pathname Description 



BM$MAP 



BM$MPB 



. MEMMGR. SOURCE . BM$MAP 



, MEMMGR. SOURCE . BM$MAP 



BM$RDM 



■MEMMGR. SOURCE. BM$RDU 



BM$W 



MEMMGR. SOURCE. BM$W 



BM$MPK 
BM$IOW 



, MEMMGR. SOURCE . BM$MAP 



.MEMMGR. SOURCE . BM$W 



BM$IOR 

BM$LNK 
BM$DEL 



, MEMMG R . SOU RC E . BM $W 



MEMMGR. SOURCE . BM$W 



, MEMMGR . SOU RC E . BM $W 



Map the specified number of bytes 
in the specified task's memory into 
the calling task. 

Map the specified number of bytes 
from general memory into the 
calling task. This routine is 
given a beet address which begins 
the area to be mapped. 

Read and update a buffer. This 
routine calls BM$RD to get the 
specified file buffer. If the 
buffer has been modified, it is 
written to the file. 

Write a buffer. This routine 
writes the specified buffer, which 
is mapped into the calling task, to 
the specified physical record of 
the file (destination address need 
not be the same as the source file 
record from which the buffer was 
read) . 

Check a mapped segment for possible 
Write Protection violation. 

Set up the I/O call block to write 
the specified buffer to the 
specified record in the file. 
After building the call block, it 
calls FM$IO to perform the I/O. 

Set up the I/O call block to read 
the specified buffer from the 
specified record on the file. 
Calls FM$IO to perform the I/O. 



Link the specified buffer onto 
TOL. 



the 



Delink the specified buffer from 
the TOL. 
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I Table 9-5 Buffer Management Routines — Part 3 of 3 
Routine Source Module Pathname Description 



BM$REL 



. MEMMGR. SOURCE . BM$REL 



BM$RMD 



BM$TRM 



. MEMMGR. SOURCE . BM$REL 



. MEMMGR. SOURCE . BM$REL 



BM$WRN 



. MEMMGR. SOURCE . BM$RDU 



Release a buffer to buffer 
management. This routine unmaps a 
buffer from the calling task and 
links it onto the TOL. Modified 
buffers are written to the file. 

This routine is the same as BM$REL 
except it presets the buffer's 
modified flag, forcing a write to 
the file. 

Trim a buffer from memory. This 
routine releases the specified 
buffer to user memory. If the 
buffer has been modified, it is 
first written to the file. 

Write a buffer and rename it. This 
routine calls BM$W to write the 
specified buffer, then modifies the 
buffer overhead to make the buffer 
correspond to the destination file 
record. 



9.6 DISK MANAGER 

The disk manager consists of a memory resident, queue-serving task and 
several system overlays. The queue server is the main driver. It 
decodes the buffered SVC opcode and links to the correct processor 
(which is a system overlay) for that opcode. The disk management 
opcodes include: 

... - deallocate a block 

1 - allocate all of the requested amount 

... 2 - allocate as much of the requested amount as 
possible 

... 3 - allocate as much as possible at the address 
requested or fail. 

Table 9-6 shows the major routines included in disk management. 
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Routine 

DM$PC 

DMALLC 



Table 9-6 Disk Management Routines — Part 1 of 2 
Source Module Pathname Description 



DSCMGR. SOURCE. DMSTSK 



L>SUi v l<iK. SUUKUi'.iJl v IAijljU 



DMDALC 



ADJALC 



DSCMGR . SOURCE . DMDALC 



DSCMGR . SOURCE . ADJALC 



ALCSCN 



DSCMGR . SOURCE . ALCSCN 



CHGMAP 



DSCMGR . SOURCE . CHGMAP 



Queue-serving main driver for disk 
management . 

Disk allocation main driver. This 
routine processes all of the 
allocation opcodes. It converts 
the requested number of file blocks 
(physical records') to a number of 
ADUs, then attempts to allocate 
according to the restrictions 
implied by the opcode. 

Deallocate disk space. This 
routine deallocates the specified 
ADUs by resetting the bits in the 
correct partial bit maps. 

Adjust allocation count. This 
routine computes the number of ADUs 
in a given block on contiguous free 
ADUs which are useful to allocate 
file physical records of a given 
ADU size. 

Allocation bit map scans. This 
routine contains two bit map scans. 
The first scans a partial bit map 
for a particular allocation 
placement (allocation must start at 
particular ADU). The second is a 
first-fit scan which starts with 
the first partial bit map and 
searches for a large enough block 
of free ADUs. 

Change disk allocation bit map. 

This routine sets or resets bits in 

the disk resident bit map to 
reflect the newly completed 

allocation or deallocation 

operation. . This routine is the 

common exit path from DMALLC and 
DMDALC . 
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Table 9-6 Disk Management Routines — Part 2 of 2 
Routine Source Module Pathname Description 



DM$TBL 



DSCMGR . SOURCE . DM$TBL 



EXTEND 



MAPPBM 



RDPBM 



WRTPBM 



DSCMGR . SOURCE . EXTEND 
, DSCMGR . SOURCE . MAPPBM 

. DSCMGR . SOURCE . RDPBM 
. DSCMGR . SOURCE . WRTPBM 



SCNBIT 



. DSCMGR . SOURCE . SCNBIT 



SETBIT 



. DSCMGR . SOURCE . SETBIT 



WCHPBM 



. DSCMGR . SOURCE . WCHPBM 



Disk management table builder. 
This routine scans the partial bit 
map currently buffered in memory, 
and fills in the disk management 
table (DMT) entries particular to 
that bit map. 

Extend an allocation across partial 
bit map boundaries. 

Map partial bit map. This routine 
reads/writes the specified partial 
bit map from/to the disk. 

Read partial bit map. This routine 
reads the specified partial bit map 
from the specified disk to the 
specified buffer. 

Write partial bit map. This 
routine writes the specified 
buffered partial bit map to tJ# 
correct sector on the speciftm 
disk. 

Scan for a bit of the opposite 
state. This routine scans a 
buffered partial bit map from the 
specified bit position until it 
finds a bit of the opposite state. 

Set bits to the given state. This 
routine sets the specified number 
of bits in a bit map, starting at 
the specified bit position, to the 
specified state (0 or 1). 

Calculate a partial bit map number 
and bit position from the specified 
ADU number. 
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9-7 DEVICE I/O PROCESSING 

In addition to the DX10 I/O supervisor, there are several other 
routines'! which are used to process device I/O calls. These other 
routines include the device driver task (DDT), the device service 
routines (DSRs), and several common routines. Table 9-7 shows the 
major routines involved in processing device I/O. 

Table 9-7 Device I/O Processing Routines 

Routine Source Module Pathname Description 



DXIOS 



DXIO. SOURCE. DXIOS 



DDT 



>XI0. SOURCE. DDT 



TMOUT 



DXIO. SOURCE. DSRTMX 



PSTXPR 



DXI . SOURCE . PSXTXPR 



DX10 I/O supervisor. This routine 
processes SVC code 0. It 
preprocesses calls for device I/O, 
file I/O, and file utility 
services, buffering the call block 
and queueing it for the appropriate 
queue server or DSR. It* also 
processes all I/O to the DUMY 
device. 

Device driver. Serves all device 
queues. Initiates device I/O, 
starts the DSRs, and does end-of- 
record processing (i.e. unbuffers 
data to tasks doing device I/O). 



Device time out check, 
routine is called by the sche 
after a system time unit 
elapsed. It scans the PDT li 
see if a device has a tim 
error, or if the re-enter-me 
in the PDT is set. If the 
enter-me flag is set, contr 
passed to the DSR. If the d 
has a time-out error the I 
aborted. 



This 

duler 

has 

st to 

e-out 

flag 

re- 

ol is 

evice 

/0 is 



Routine which tests a file 
request, .DXIO. SOURCE. PSTXPR, 
see if a "fast transfer" 
possible. 



I/O 
to 
is 



Table 9-8 shows the Device Service Routines included with DX10. Note 
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Table 9-8 Device Service Routines 



Routine Description 

CAS733* DSR for cassette units on a 733ASR. 

CRDSR DSR for 804 card reader. 

DDIOSR DSR for direct disk I/O. 

DSR91 1 DSR for 911 VDT. 

DSR913 DSR for 913 VDT. 

DSR979 DSR for 979 magnetic tape drive. 

DSRKSR* DSR for 733 KSR and 743 KSR. 

FPYDSR DSR for FD800 diskette. 

LPDSR DSR for 306, 588, 810, 2230 and 2260 

line printers. 4 

DSR820 DSR for 820 keyboard device. 

DSRTPD DSR for teleprinter devices 



Source Module 
Name 

.CAS7T5 

.CRDSR 

.DDIOSR 

.DSR911 

.DSR913 

.DSR979 

. DSRKSR 

.FPYDSR 

.LPDSR 

.DSR820 
.DSRTPD 
.COMISR 
.TTYISR 
.TPDCOM 



* CAS733 and DSRKSR are linked to form DSR733 for the 
733 ASR. 



Several routines commonly used by DSRs are contained in the source 
module .DXIO. SOURCE. I OCOMX. The routines are: 



BZYCHK 

SETWPS 

ENDRCD 

XFERM 

GTADDR 

MAPCHK 

BUFCHK 

BRCALL 
BRCALT 
JMCALL 
JMCALT 



See if device is busy. 

Set up interrupt mask and workspace. 

Activate end-of-record routine (part of DDT). 

Put format (direct disk I/O) data in buffer. 

Calculate a 20-bit absolute address from a 16-bit 
mapped address (used by DSRs for TILINE devices). 

Verify that the specified address is mapped into a 
user's space. 

Verify that a buffer is mapped into a single 
base/limit register pair. 

Branch table call. 

Alternate branch table call. 

Jump 'table call. 

Alternate jump table call. 
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SCNPDT 

PUTEBF 

PUTCBF 

GETC 

KEY FUN 
TILERR 

ASCCHK 



Scan PDT list, and enter power-up routine for each 
device. 

Put a character in the event character buffer (for 
keyboard DSRs) . 

Put a character in the character queue (for keyboard 
DSRs) . 

Get a character from the event buffer or character 
queue (for keyboard DSRs) . 

Recognize HOLD, ABORT, or BID keys from a keyboard. 

Move the TILINE image to the system log buffer in 
the PDT extension for TILINE devices (used by disk 
and magnetic tape DSRs) . 

Compare an ASCII character to a table of characters 
and transfer control to the address associated with 
the matched character. 



9.8 FILE UTILITY ROUTINES 

File utility SVCs are queued by DXIOS for the file utility task, FUTIL 
(task >0B on the system program file) . FUTIL consists of a main 
driver, FU$, and several routines to process the different file utility 
opcodes. It also contains two conversion routines, LC$ and FC$, which 
convert the still supported librarian and FUR call blocks to DX10 3.0 
file utility call blocks. 

Table 9-9 shows the major file utility routines which make up the file 
utility task, FUTIL. Note that all utility source modules are 
cataloged under the library .FUTIL. SOURCE on the source disk. 
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Table 9-9 File Utility Routines — Part 1 of 5 
Routine Source Module Pathname Description 



PU$ .FU$ Main driver and queue server for 

file utility requests. Decodes 
file utility opcode and branches to 
correct processor. If opcode is 
FUR or librarian, branch to FC$ or 
LC$, respectively. 

PC$ .FC$ Convert FUR call to new call block. 

This routine converts the call, 
calls UC$ to execute it, calls 
CLEAN to unbuffer the call, then 
returns to FU$. 

LC$ .LC$ Convert librarian calls to new call 

block. This routine converts the 
call, processes it, calls CLEAN to 
unbuffer the call block, then 
returns to FU$. 

UC$ .FU$ Normal utility call processor. 

This routine checks for bad 
opcodes, looks up the correct 
processor for the given opcode 
(table is in FU$ also), and 
branches to that processor. The 
processor returns to UC$, which 
returns to the caller (either FU$, 
LC$, or FC$). 

AA$ .AA$ Add alias opcode processor. This 

routine adds an alias to an 
existing file. A LUNO must have 
been previously assigned to the 
file. Return is to calling task 
(UC$). 

I$ADR .AA$ Initialize alias descriptor record. 

This routine initializes a buffered 
ADR (see section on disk data 
structures) and then returns to 
AA$. 

AL$ .AL$ Assign LUNO opcode processor. This 

routine assigns a LUNO to either a 
file, a device, or a temporary 
file. It also builds the necessary 
FCB/LDT tree in the system table 
area. 
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Routine 
CF$ 

DP$ 



Table 9-9 Pile Utility Routines — Part 2 of 5 
Source Module Pathname Description 



CP$ 



DPS 



RP$ 



RP$ 



RL$ 



RL$ 



RL$LOTT 



RL$ 



SP$ 



UP$ 



SF$ 



UP$ 



Create file opcode processor. This 
routine creates a file, including 
an FDR on disk, disk allocation for 
the file, and an FOB in memor^* 

Delete protect opcode processor. 
This routine sets the delete 
protect flag "bit in both the FCB 
and the PDR (on disk) for the 
specified file. 

Rename file opcode processor. This 
routine moves the existing PDR to 
the destination directory and 
releases the old PDR directory 
entry. If an existing file has the 
new pathname, it is replaced by the 
renamed file. 

Release LOTTO opcode processor. 
This routine sets up registers 
using values from the buffered call 
block, calls RL$LUN to release the 
LOTTO, then returns. 

Internal entry point to release 
LOTTO opcode processor. This 
routine calls LDTSCH to find the 
LDT for the specified LOTTO. The 
LDT is delinked from all chains, 
and any file buffers associated 
with the released LOTTO are flushed 
(released). The LDT is released to 
system table area. 

Set forced write flag opcode 
processor. This routine sets the 
force'd write flag in the specified 
LDT to the specified state. 

Unprotect file opcode processor. 
This routine reads the PDR for the 
specified file from its parent 
directory, resets the protection 
flags in the PDR to zero, and 
rewrites the PDR back to the 
directory. 
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Routine 



Table 9-9 Pile Utility Routines — Part 3 of 5 
Source Module Pathname Description 



VP$ 



WPS 



DA$ 



WP$ 



DA$ 



DPS 



DP$ 



ALSPNC 



AL$ 



T$PILE 



.AL$ 



T$ADD 
GENLUN 

DEVSCH 



.AL$ 
.ALS 

.AL$ 



Verify pathname opcode processor. 
This routine checks a pathname for 
valid syntax, and then tries to 
find the file. If the file exists, 
relevant information is returned. 

Write protect opcode processor. 
This routine sets the -write protect 
hit in the PDR for the specified 
file. 

Delete alias opcode processor. 
This routine delinks the alias 
descriptor record for the specified 
alias from the alias list in the 
directory file (see the section on 
disk data structures) . 

Delete file opcode processor. This 
routine releases all primary and 
secondary file allocations on the 
disk and releases all directory 
entries (PDRs and ADRs) . 

Assign LUNO to pathname component. 
This routine returns the PCB 
address for the specified pathname 
component. If no PCB exists, one is 
built and added to the PCB/LDT 
tree. 

Assign LUNO to temporary file. 
This routine generates a unique 
pathname for the temporary file, 
then calls AL$ to assign the LUNO 
to it. 

Add a new PCB node to the PCB/LDT 
tree. 

Generate a unique LUNO. This 
routine searches a given LDT list 
and returns a LUNO not currently 
existing in the list. 

Search PDT list for device name. 
If the desired device is found, the 
PDT address is returned. 
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Routine 
VOLSCH 



Table 9-9 File Utility Routines — Part 4 of 5 
Source Module Pathname Description 



AL$ 



AL$DEV 



AL$PIL 



AL$PAR 



B$FDR 



AL$ 



AL$ 



AL$ 



CP$ 



P$INIT 


.CP$ 


C$DPLT 


.CP$ 


CRBLK 


: .CP$ 



A$BLK 



R$DSC 



CP$ 



DPS 



Search the volume tables for volume 
name. If the specified volume has 
been installed, the PDT address of 
the drive on "which it isinstalled 
is returned. 

Assign LDTTO if a device. This 
routine searches the PDT list for 
the desired device and assigns a 
LUNO to it. 

Assign LUEFO to file. This routine 
gets the system table area and 
builds an LDT for a LUNO to assign 
to a file. 

Assign LUNO to parent. This 
routine assigns LUNO >CA to the 
parent directory file of the 
specified file. 

Build a file descriptor record and 
write it to the specified directory 
record. 

Initialize a file based on its file 
type. 

Compute file creation parameter 
defaults, based on file type. 

Compute the number of file physical 
records required for a file based 
on file type and specified initial 
allocation. 

Allocate the specified number of 

physical records on the disk. This 

routine calls the disk manager to 

allocate the required disk space. 

Release disk space. Calls the disk 
manager to release the primary file 
allocation and all secondary 
allocations . 
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Table 9-9 File Utility Routines — Part 5 of 5 
Routine Source Module Pathname Description 



R$FDR 



RSALS 



FLLRMV 



.DF$ 



.DF$ 



.RL$ 



CLEAN 



.FU$ 



Release file descriptor records. 
Releases all FDR entries in the 
directory for the file "being 
released . 

Release aliases. Releases all ADR 
entries in the directory for 
aliases of the file being deleted. 

Remove and clean up file LDT. 
Delinks a file LDT from all chains. 
If the file to which the LDT was 
assigned has no more LUNOs assigned 
and no descendants, its FCB is 
released. 

Clean up request. Calls TMQUE to 
queue the buffered call block for 
the SVC clean up task, SVCCLN. 



Many routines commonly used by file utility processors are contained in 
the file .FUTIL. SOURCE. US$. Some of the routines included are: 

LDTSCH - search the LDT tree at the specified level (task, 
station, global) for the specified LDT 

FNDLUN - find the specified LDT (level does not matter) 

LDTRMV - remove the specified LDT from all chains 

LDTENT - enter the specified LDT in the LDT tree 

HASH - compute a hash key value for the specified 
pathname component 

LOOKUP - look up the specified file by name 

I$BLK - initialize file blocking buffer 

G$REC - transfer the specified directory record to the 
caller's buffer 

FILE10 - performs all disk I/O for FUTIL 

T$CLEN - clean up the FCB tree (release all unnecessary 

FDBs on the upward path from a single leaf node) 

FDRFCB - translate a buffered FDR and associated blocks 
into an FCB 
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9-9 FILE MANAGER 

Pile management under DX10 consists of a pool of memory resident, 
queue serving tasks and four system overlays. The main driver of each 
task is a routine called FMSTSK. This routine is activated whenever 

the T /0 emT)pryi snr . "nYTOS . n1cir>oa an on-h-r-tr on -i +-cs mio-no "PMUmcfV 

dequeues each entry and passes control to the correct processor for the 
specified I/O opcode. The processor returns to FMSTSK, which unbuffers 
the I/O call block, reactivates the calling task, and gets the next 
entry on the queue. FM$TSK issues an SVC >24 when its queue is empty. 
Table 9-10 shows the major routines that process file I/O calls. All 
source modules are in directory .FILMGR. SOURCE. 

Table 9-10 File I/O Processors — Part 1 of 2 



Routine 
FM$TSK 

FMOPEN 



FMCLOS 

or 
FMCLTJW 

FMCLEF 



FMOPRW 
FMRDST 

FMFBSP 
FMREAD 



Description Overlay 

Main driver of file manager. N 
Looks up opcode in table, 
branches to correct processor. 

Open file processor. Checks N 
access privileges for conflicts. 

Close file processor. File N" 
buffers are updated to disk, 
locked records are unlocked. 

Close file with EOF. Writes Y 
end-of-file, then calls FMCLOS. 

Open and rewind file processor. Y 
Calls FMOPEN, then to FMRWND. 

Read file status processor. Y 
Calls BM$MAP to map in user 
buffer, then writes file 
characteristics in buffer. 

Forward/backward space processor. Y 
Calls FBSP to reset LDT pointers. 

Read ASCII and read direct N 
processor. Calls BM$MAP to 
map in user buffer, then calls 
BM$RD (blocked file) or FM$I/0 
(unblocked) to get proper 
physical record. Transfers 
proper logical record to user 
buffer and releases file buffer 
(if blocked file). 



Source Module 
Name 



•FM$TSK 

.FMOPEN 
.FMCLOS 

.FMCLEF 
.FMOPRW 
.FMRDST 

.FMFMBSP 
.FMREAD 
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Routine 
FMWRIT 



FMWEOF 



FMRWND 



FMRWRT 



FMACES 



FMOPXT 



FMOPUB 



FM$I0 



Figure 9-10 File I/O Processors — Part 2 of 2 

Source Module 
Description Overlay Name 



Write ASCII and write direct N 
processor. Calls BM$MAP to map 
in user "buffer, then gets proper 
physical record through BM$RD 
(blocked file). New logical 
record transferred (via FMSIO 
if unblocked). Buffer (if any) 
is released. 

Write end-of-file processor. Y 
Writes an EOF (zero length) 
record to a sequential file. 
EOFs to relative record files 
are ignored. 

Rewind file processor. Resets Y 
LDT pointers to show that the 
file is rewound (before the 
first file record) . 

Rewrite record processor. T 

Backs up one record on a 
sequential or relative record 
file and writes the user's 
buffer to that record (calls 
FMWRIT to write). 

Modify access privileges N 

processor. Checks for access 
conflicts between different 
users of a file; if none, 
modifies LDT flags to reflect 
new privileges. 

Open extend processor. Calls Y 
FMOPEN to open the file, sets 
LDT pointers to end-of-medium, 
then backspaces over any EOFs 
at end of file. 

Open for Unblocked I/O. Calls Y 
FMOPEN to open the file, then 
sets flag in LDT to allow 
unblocked I/O to the file. 

File manager disk I/O routine. N 
Maps file physical record no. 
into ADU/sector offset disk 
disk address and transfers data 
between user buffer and disk. 



.FMWRIT 



.FMWEOF 



.FMOPRW 



.FMRWRT 



.FMACES 



.FMOPXT 



FMOPUB 



FMSIO 
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9.9.1 KEY INDEXED PILES. 

Key indexed file I/O processing is a major part of file 
management. KIP I/O processing routines are contained in one memory 
resident linked object module, KIP, and five system overlays. Table 9- 
11 shows the major routines involved in key indexed file I/O 
processing. All source modules are in directory .KIPILE. SOURCE. 

Table 9-11 Key Indexed Pile I/O Processors — Part 1 of 2 



Routine 
KI$BEG 



0LN002 



0LN008 * 



KI$BTD 



0LN009 



KI$RR 



Description 



Key indexed file I/O driver. 
Receives key indexed file I/O 
requests from PM$TSK, decodes 
opcode, and branches to cor- 
rect processor. 

Insert record into key indexed 
file, using the primary key. 
Key is hashed to get a block 
number and then record is in- 
serted. Key is added to B-tree 
for primary key. 

Delete a record from a key 
indexed file, either by key 
value or currency information. 
Record is removed from block 
and key values from B-trees. 

Delete an entry from a B-tree. 
Searches a B-tree for the 
specified key. If found, entry 
is deleted. If the B-tree entry 
is a B-tree divider (see section 
on disk organization) , 0LN009 is 
called to delete the entry from 
the next higher node in the 
B-tree. 

Continuation of B-tree delete 
routine. 

Read a record from a key 
indexed file. If no currency 
information is provided, searches 
B-tree for specified key and sets 
up currency. Calls BMSMAP to map 
in user buffer, reads desired 
record using currency information, 
releases file blocking buffer. 



Overlay 

N 



N 



N 



Source Module 
Name 

.KI$BEG 



0LN002 



. 0LN008 



.KI$BTD 



0LN009 



KI$RR 
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Table 9-11 Key Indexed File I/O Processors — Part 2 of 2 



Routine 
KI$SC 



KI$RN 



KI$BIT 



0LN001 
KI$BTS 



KI$GRF 



0LN004 
0LN0O3 



Description 



Overlay 



Driver for set currency commands. N 
Sets user's currency information 
to point to the data record and 
the B-tree position corresponding 
to the specified key value. 

Read next record. Uses currency N 
information to find record con- 
taining next largest key, calls 
KI$RD (same as BM$RD) to read 
the record. 

Insert an entry into a B-tree. N 
Inserts a new key value in the 
proper leaf node of the B-tree. 
If the node becomes full, calls 
0LN001 to split the leaf into 
two new nodes and add an entry 
to the next higher node. 

B-tree split routine. Y 

Search B-tree for specified key N 
value. If found, a stack that 
traces the path down the B-tree 
to the correct leaf node is 
created; otherwise, the routine 
finds the leaf node in which the 
key should fit if it existed, and 
the stack is still created. 

Get free block. This routine is N 
used to get an overflow block or 
B-tree block from the free block 
chain. If the last free block is 
returned, another secondary 
allocation is made to the file. 

Open random and close opcode Y 
processor. 

Subroutines used by KI$RW Y 
(rewrite). This overlay contains 
three pieces of code used by KI$RW 
(rewrite) . 



Source Module 
Name 

.KI$SC 



.KI$RN 



.KISBIT 



.0LN001 
.KI$BTS 



.KI$GFR 



. 0LN004 
. 0LN0O3 
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SECTION 10 
SYSTEM COMMAND INTERPRETER 



10.1 GENERAL 

This section describes the routines that make up SCI, as well as the 
data structures and files used "by the command interpreter. In this 
description, SCI is divided into four parts: the command interpreter, 
the background resource manager, the "background task bidder, and the 
output queuer. The following paragraphs describe those parts of SCI. 



10.2 SYSTEM COMMAND INTERPRETER 

The function of the command interpreter, SCI9 C '0, is to interpret 
commands entered at a user terminal or listed in a sequential file. 
The command language consists of a set of primitive operations, whose 
names start with a period (e.g., ".BID"), and a procedure definition 
and parameter gathering facility that permits the user to extend the 
set of commands. 

SCI990 executes in both batch and interactive modes. In interactive 
mode, the terminal user may be prompted for the values of command 
parameters. In batch mode, parameters are specified by keyword 
assignments in the command statement. Except for accessing the 
commands and their parameters, the command interpreter is essentially 
indifferent to the mode of operation. This document mentions a mode of 
operation (Batch, VDT, TTY) only when the description does not apply to 
all modes. 

10.2.1 STRUCTURE OP SCI. 

SCI990 has two functions, parsing and then executing a command. The 
parsing function includes: displaying menus and messages; and 
reprompting for invalid input. The execution of a command may be 
performed internally (for primitive operations) or result in evaluation 
of a procedure definition. Figure 10-1 shows a generalized flow of 
control through SCI990. 

The structure of the system command interpreter is composed of direct 
procedure calls. Indirect calls ("A" calls "B" calls "C") are listed 
in a cross reference table at the end of this section. 
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Figure 10-1 SCI Plow of Control 
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10.2.2 OVERLAY STRATEGY . 

There are two kinds of overlays for the system command interpreter 
task. One kind is the overlay structure designed for use with the 
•OVLY primitive command (executed by the S$OVLY routine). The text 
editor and debugger are examples of this kind. Other overlays, such as 
PARSER and secondary overlays of the debugger, do not use the .OVLY 
structure, but are loaded by means of a Load Overlay SVC. 

The command interpreter itself has two overlays that are part of its 
basic operation. PARSER contains the bulk of the routines used for 
parsing a command, expanding a procedure definition, and executing a 
primitive command. The PARSER overlay is loaded as needed by the 
GETCMD routine. DERROR contains the error formatting and display 
routines (including the English language text for messages) and the 
log-in/log-out routines. The DERROR routines are accessed by means of 
S$0VLY while the PARSER routines are accessed by means of a Load 
Overlay SVC. 

A third overlay, TINPO, may be considered part of SCI990 proper. TINPO 
contains the command processors for the following commands: 

LTS - List Terminal Status 

MTS - Modify Terminal Status 

SBS - Show Background Status 

KBT - Kill Background Task 

MSG - Display Message at Own Terminal 
CM - Create Message 

AUI - Assign User ID 

DUI - Delete User ID 

MUI - Modify User ID 

LUI - List User IDs 

WAIT - Wait Eor Background Task To Complete 

A fourth overlay, OUTQUE, contains the command processors for the 
output queue r: 

PP - Print Pile At Device 

HO - Halt Output At Device 

RO - Resume Output At Device 

KO - Kill Output At Device 

SOS - Show Output Status 

Other overlays are supporting routines for various command processors, 
such as the text editor and debugger. 

The general strategy for partitioning the command interpreter between 
the shared procedure area, SCI, and the PARSER overlay is to attempt to 
keep the size of the shared procedures plus the task area plus the 
largest overlay as small as possible, but to make the shared area as 
large as possible. Any of the routines in the PARSER overlay can be 
moved into the shared procedure SCI should PARSER become the largest 
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overlay. However, care should "be taken in moving routines from SCI to 
PARSER, since PARSER is only loaded by GETCMD and many of the routines 
(e.g., PUTLINE, GETFIL) may be called when PARSER is not loaded. For 
example, GETFIL is called during error recovery from a procedure 
expansion, which may occur while a user overlay is loaded. 

10.2.3 DATA STRUCTURES. 

The following paragraphs describe the internal data structures created 
and maintained by SCI. 

10.2.3.1 System Communication Area (SCA). 

The SCA is an area of memory shared fas a "dirty" procedure) by all 
command interpreters, the background resource manager and the 
background request handlers (QBID, OQUEUE) . The SCA contains a table 
of global system data, such as global LUNOs and task bid IDs, plus a 
table called an SCA entry for each terminal that uses SCI990. 



10.2.3.2 SCA Entry. 

Each terminal has a 32-byte entry in the SCA for communication between 
the system command interpreter and the background resource manager 
(BRM) . The fields of the SCA entry are labeled and defined as follows. 

Terminal Type 

Terminal ID 

Terminal Device Name 

User ID 

EG Opcode 

BG Opcode 

PG Error Code 

BG Error Code 

EG Status 

BG Status 

PG Task ID 

BG Task ID 

PG Task LUNO 

BG Task LUNO 

PG "CODE" Value 

BG "CODE" Value 

PG Return Code (CC) 

BG Return Code (CC) 

PG SCI Task ID 

BG SCI Task ID 



SCA&TT 


EQU 





SCASTI 


EQU 


1 


SCASDV 


EQU 


2 


SCASUI 


EQU 


6 


SCASFO 


EQU 


12 


SCA$B0 


EQU 


13 


SCASFE 


EQU 


H 


SCASBE 


EQU 


15 


SCASFS 


EQU 


16 


SCASBS 


EQU 


17 


SCA$FT 


EQU 


18 


SCA$BT 


EQU 


1Q 


SCA$FL 


EQU 


20 


SCASBL 


EQU 


21 


SCASPC 


EQU 


22 


SCASBC 


EQU 


23 


SCASFR 


EQU 


24 


SCA$BR 


EQU 


25 


SCASFI 


EQU 


26 


SCASBI 


EQU 


27 
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The fields SCA$TT, SCA$FS, and SCA$BS are subdivided as follows: 



SCA$TT 

Bit 



1-3 
4-7 



BYTE 



Terminal/User Type Information 



1 a Terminal is disabled 
User privilege code (0-7) 
Current terminal mode 

« Batch mode 

1 « TTY mode . 
F * VDT mode 

Memory images of every user's TCA are maintained on disk in a library 
of user TCA images. During the log-in process, a user's TCA image is 
loaded into the SCI990 task. When the TCA is passed from one system 
task to another, it is transferred via the medium of a record on a 
background or foreground TCA file. The overall layout of the TCA is 
shown in Figure 10-2. 



SCA$FS 

Bit 


1-3 



BYTE 16 



Foreground Status 



1 s Login is required 
Default user privileges 
Default terminal mode 

» Batch mode 

1 « TTY mode 
F * VDT mode 



SCA$BS 

Bit 


1 
2 
3 

4-7 



BYTE 17 



Background Status 



1 =; BG Task pending 
1 » Message pending 
1 * BG Task complete 
1 * BG Task bid error 
Reserved 



10.2.3-3 Text String. 

Strings of characters are uniformly represented within SCI990 as a 
series of bytes and a pointer. The first byte, which is addressed by 
the pointer and may be on an odd byte address, contains the count of 
the number of characters in the string. The following bytes contain 
the characters. The null (empty) string is represented as a string 
with length zero. 
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An output buffer for a routine which returns a string value usually 

must have the buffer capacity in the first byte so that buffer 

overflows can be prevented. Some examples of string constants and 
buffers follow: 

STR1 BYTE 10 

TEXT 'STRING ONE' 

BUF1 BYTE 31 

BSS 31 

Note that the first (count) byte is not included in the count. The 
count refers to the number of following bytes. 

10.2.3.4 Terminal Communications Area (TCA). 

The terminal communications area (TCA) has three purposes. First, 
it contains a description of the user currently logged in at the 
terminal. This description includes his user ID, status,- encoded 
passcode, and allotted terminal time. Secondly, the TCA contains the 
name correspondence table (NCT) belonging to the user. The NCT 
contains the user defined synonyms and their values. Thirdly, the TCA 
is used to pass information, including parameters, from one system task 
to another. These task parameters are embedded in the NCT. 

Hex. 

Byte 

* * 

>00 ! LENGTH OP TCA j 

+ + 

>02 ! OFFSET TO TERMINAL STATUS BLOCK ! 

+ + 

>04 ! RESERVED ! 

+ j 

>06 j RESERVED 1 

+ + 



1 

1 

+ j 

>0A | OFFSET TO END OF NCT 1 

+ j 

>0C j 1 

TERMINAL STATUS BLOCK 



>08 ! OFFSET TO NAME CORRESPONDENCE TABLE (NCT) 



! : 

. ; 

NAME CORRESPONDENCE TABLE 

I ! 

* ._— * 



Figure 10-2 TCA Layout 
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10.2.3-5 Terminal Status Block (TSB). ■■ 

The TSB, as shown in Figure 10-3, is used to identify the logged- 
in user to the various command processors. The encoded passcode 
permits passcode verification without exposing the actual passcode 
value. The user status information is copied to the terminal SCA entry 
at log-in, and specifies the level of user capabilities in the system. 

Thg "Pf?- "h n sir r»n-mT\T cfh t r\r\ /->pr1o no +V10 ma A -i -mm "Ktt tjj-Vi •? r»V> T?fl + q oV /->oT""n"' »+ -* r>r* 

codes are returned (those tasks executed with ".BID"). 

Hex. 

Byte 

-x- . * 

>oo | ! 

I USER ID (6 CHARACTERS) j 

i i 

+- + 

>06 ! FOREGROUND TASK COMPLETION CODE j 

>08 ! ENCODED PASSCODE j 

>0A j USER STATUS j 

>oc i i 

~ RESERVED 

i i 

i i 

+_- + 

>H ! 

I ! 

I I 

+ _ + _ + 

>18 j MAX DES SIZE \ ACTUAL DES SIZE j 

+ + + 

i 

USER DESCRIPTION TEXT 



>1A ' ' 



i i 

i i 

* . , * 



>2A * 



Figure 10-3 Terminal Status Block 



10.2.3-6 Name Correspondence Table (NCT). 

The NCT, as shown in Figure 10-4, consists of pairs of text 
strings terminated by a zero byte. Each text string is formed from a 
series of characters preceded by the count of the number of characters. 
A length of zero is not permitted. User defined synonyms may consist 
of printable characters only. 
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Positional parameters (elements of the "PARMS" list on a .BID, .QBID, 
or . OVLY command) are transmitted to the command processor program via 
special entries of the following form: 

Byte 3, 0, 0, Parameter Number Synonym 

Byte 15 

Text 'DS02. SYS. SOURCE' Value 

A program completion message (argument R2 of S$ST0P) returned by a task 
executed via a .BID or .QBID command is transmitted back to the FG- 
command interpreter as a bogus parameter 0. 



SIZE OF SYN 1 NAME 



SYNONYN 1 NAME 
TEXT 



SIZE OF SYN t VALUE 



SYNONYM 1 VALUE 



SIZE OF SYN 2 NAME 



jd. 



(END OF NCT) 



2278142 



Figure 10-4 Name Correspondence Table 



10.2.4 INTERFACES. 

SCI interfaces to the user, and to various SCI routines, through 
the terminal and several files. The following paragraphs describe the 
interfaces. 

10.2.4*1 Calling Sequence. 

The calling sequence for SCI990 depends on the mode of operation. 
In interactive (VDT or TTY) mode, the SCI task is bid by the operating 
system in response to the user entering RESET followed by an 
exclamation mark " ! " . In batch mode, the task is bid by the QBID 
mechanism (see paragraph 10.4) as a result of an XB command. The mode 



Texas Instruments 



10-8 



9*591 53-9701 



System Design Document 



System Command Interpreter 



is determined by the four bytes passed as parameters of the Bid Task 
SVC, which are formatted as follows: 

* . . -i * 

! TYPE J STATION ID j 
+ + + 

! RESERVED j 

* . * 

The TYPE field is a copy of the SCASTT (terminal type) field in the ter 
minal SCA entry. The STATION ID is the terminal (station) number. In 
interactive mode, both the type and STN ID fields are zero and the 
information is derived from a SELFID SVC and the SCA entry. In batch 
mode, the fields are (and must be) non-zero to distinguish the mode. 

10.2.4-2 Terminal Local Pile. 

The terminal local file (TLF) is a buffer on disk for lines to be 
displayed to the user. The lines are buffered so that VDT users can 
scroll back and forth through them and so they can be listed together 
in batch mode. The name of the file is determined from the SCI mode 
and the terminal number as follows: 



FOREGROUND : 
BACKGROUND : 



SSFTLF** 
SSBTLF** 



where 
where 



** s terminal number 
** « terminal number 



The interactive modes of SCI run in the foreground, while the batch 
mode executes in background. 

The TLF is written to by the S$I0 routines: SSOPEN, S$¥RIT, S$WEOL, 
and S$CL0S. Whenever SCI990 prepares to input a new command, the TLF 
is displayed (TTY, VDT modes) or listed (batch mode) by the S$SHO¥ 
routine . 

10.2.4.3 System Procedure Library. 

Commands are mapped into procedure file names by concatenating 
them on the end of the current procedure library name. Unless the user 
overrides the default PROC library name with a .USE command, the 
standard system PROC library is used. This directory is named . SSPROC . 

10.2.4.4 Menu Files. 

Menus are displayed in VDT mode by displaying the contents of a 
menu file. Menu files are named by concatenating the name of the 
system PROC library, the characters f, .M$", and the menu name. The 
default menu file is .S$PR0C.M$LC , which is also displayed in response 
to M /LC" . 
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10.2.4-5 TCA Library Pile — . S$TCALIB. 

The terminal communication area (TCA) is described in paragraph 
10.2.3.4 A TCA image is created for each user when his user ID is 
assigned. This TCA image resides on the TCA library file .S$TCALIB 
while the user is not logged in. Each record of the TCA library file 
holds exactly one TCA image. The number of the record containing the 
TCA image for a particular user ID is the same as the numeric part of 
the ID. For example, a user ID of "ABC010" uses record 10 (or >A) or 
the TCA library file. The numeric parts of user IDs must therefore be 
unique. Since the TCA library is implemented as an unblocked, relative 
record file, DX10 allocates records in blocks. Thus it is desirable 
that the record numbers be grouped, preferably by assigning them 
sequentially starting at 1 . Unneeded user IDs can be deleted and their 
TCA library records reused by assigning the same numeric part of the 
ID. For example, delete user ABC010 and assign user DEF010. 

The TCA library file .S$TCALIB is accessed only during log-in and log- 
out (in the DERROR module) and by the command processors for AUI, DUT, 
LUI, and MUI (in the TINFO module). The byte field SCA$L5 in the SCA 
module defines the globally assigned LUNO used for accessing the TCA 
library file (>03). 

10.2.4.6 Foreground TCA File — .SSFGTCA. 

When a user logs in at a terminal, SCI990 reads his TCA image into 
memory. While the user is logged in, this TCA image is used by the 
various command processors to maintain his list of synonyms, maintain a 
history of the status of his operations, and transmit parameter values 
and messages between the various components of the SCI system. When a 
command processor is implemented as a task separate from SCI990, the 
TCA image is written to a record of the foreground TCA file for the 
command processor task to read it. Routines S$PTCA and SSGTCA put and 
get the TCA, respectively. The record number of TCA file is the same 
as the terminal number. The foreground TCA file, S$FGTCA, is accessed 
through the global LUNO found in byte SCA$L3 of the SCA module. 

10.2.4.7 Background TCA File — .SSBGTCA. 

The background TCA file, .S$BGTCA, is similar to the foreground 
TCA file. This file is used for communication between the 
batch/background SCI and its command processors. In addition, the 
background TCA file is used for passing synonyms and parameters to 
tasks which are executed through QBID. The QBID task "freezes" the 
foregound TCA image on record "I" of the foreground TCA file (where "I" 
is the terminal number) onto record "I" of the background TCA file when 
the background task bid request is made through the background request 
manager. The background TCA file is accessed through the global LUNO 
found in byte SCA$L4 of the SCA module. 
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10,2,5 SVC OVERHEAD ANALYSIS. 

The following four subsections detail the use of DX10 SVCs, 
primarily for I/O, which are necessary for the execution of a typical 
.BID or .OVLY program. The .BID and .OVLY cases assume a task or 
overlay which accesses the TCA for parameters or synonyms and generates 
a listing on the terminal local file. An analysis is presented in 
paragraph 10.2.5.5. 

10.2.5-1 -BID SVC Overhead for Foreground SCI990. 

Table 10-1 shows the SVC overhead incurred by 8CI990 while 
processing a .BID command. In the timing estimates, the Bid Task SVC 
cost includes the overhead for End Task processing. The overlay for 
the Open-Extend of the TLP is assumed to be on disk. 

Table 10-1 .BID SVC Overhead for SCI 



Routine SVC 



XBID 01 - Close the terminal 
S$PTCA 00 - Open .S$FGTCA 
OC - Write direct, 1 
01 = Close .S$FGTCA 
S$BID 2B - Bid task 
S$GTCA 00 - Open terminal 

00 - Open .S$FGTCA 
OA - Read direct, 1 

01 - Close .S$FGTCA 
S$OPEN 12 - Open-extend TLP 

TOTALS 





Time 


Disk 




(Msec) 


Accesses 


nal 


4.4 







4.7 





record 


1 1 .4 


1 




5.9 







36.2 


2 




4.5 







4.7 





record 


11 .3 


1 




5.9 





i 


25.9 


2 



119.6 



10.2.5.2 .BID SVC Overhead In The Task Being Bid. 

Table 10-2 shows the SVC overhead incurred by a task being bid 
through .BID. In the timing estimates, the (91) LUNO assignment to the 
TLP requires no disk accesses because the SCI task has a previously 
assigned LUNO attached to the file. This also reduces the timing from 
about 42 msec to 17 msec. The (12) open-extend estimate assumes that 
the overlay is in memory and the TLP is empty. If it is not empty, the 
estimate would be (18, 2, 1). The TLP is closed during task 
termination. The overhead for task termination is assumed in the Task 
Bid in paragraph 10.2.5-1. 
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Routine 

S$NEW 
S$GTCA 



S$OPEN 
S$PTCA 



Table 10-2 Overhead in the Bid Task 



SVC 



17 - Get Bid Parameters 

00 - Open .S$PGTCA 

OA - Read direct, 1 record 

01 - Close .S$PGTCA 

91 - Assign LUNO to TLP 
12 - Open-Extend TLP 

00 - Open .SSFGTCA 

OC - Write direct, 1 record 

01 - Close .S$FGTCA 

TOTALS 



Time 


Disk 


(Msec) 


Accesses 


.2 





4.7 





11.3 


1 


5-9 





17.0 





9.7 





4.7 





11 .4 


1 


5-9 






70.8 



10.2.5-3 .OVLY SVC Overhead for SCI990. 

Table 10-3 shows the overhead incurred by SCI in executing an 
.OVLY command. Since an overlay is part of the SCI task, the TCA is 
available in memory and the TLP is already open. 



Routine 
S$OVLY 



Table 10-3 .OVLY SVC Overhead for SCI 



SVC 
14 - Load Overlay 



Time 
(Msec) 

19.2 



Disk 
Accesses 



10.2.5.4 .OVLY SVC Overhead in the Overlay. 

For overlays, S$GTCA and S$RTCA access the TCA directly in memory 
and require no I/O. The TLP is not actually opened and closed by 
S$OPEN and S$CLOS, so the only TLP I/O overhead is in the actual write 
SVCs, which are ignored in this analysis. Therefore, no overhead is 
incurred by the overlay being bid through an .OVLY command. 

10.2.5.5 Analysis. 

The assumptions made for this analysis are neither best nor worst 
case and are probably typical. It is further assumed that the cost of 
a disk access is approximately 100 msec for a DS31/32 disk drive and 60 
msec for a DS25/50 disk drive. The SVC overhead for a typical .BID is 
then about 986 msec (114-9 + 70.8*185.7 msec, 6+2*8 disk accesses). 
The SVC overhead for the same program executed as an .OVLY is then 219 
msec (19.2 msec, 2 disk accesses). The overhead for writing lines to 
the TLP is the same in both cases and is ignored, as is all other 
processing done by the program. For short functions, a .BID costs four 
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times as much as an . OYLY in system overhead and terminal response 
time. In both cases, the response time is on the order of a second or 
less . 



10.3 BACKGROUND RESOURCE MANAGER 

The Background Resource Manager (BRM) manages the background 
resources of the DX10 system command interpreter. These resources 
include the background task execution facility (QBID) and the output 
queuer (OQUEUE). BRM polls the SCA for background service requests 
from user terminals and bids the appropriate program to handle the 
request. It does not service requests itself and is not aware of the 
meaning of the requests it manages. Adding background services may be 
accomplished by adding background tasks to the system. 

10.3.1 STRUCTURE OP BRM. 

The BRM program consists of three modules, a task and two 
procedures. The first procedure is the system communication area 
(SCA), which contains the SCA entries which are polled for service 
requests. The second procedure is the background communication area 
(BCA) through which BRM communicates with QBID and OQUEUE. The task 
contains the actual BRM code and data. Both the SCA and BCA are 
"dirty" shared procedures. The SCA is described in the earlier 
discussion of SCI990. The BCA is described in paragraph 10.3-3. 

10.3.2 CALLING SEQUENCE. 

The BRM must be placed into execution before any SCI background 
service request is made through the SCA. This is normally done by 
bidding BRM from the DX10 system restart task. BRM then waits in a 
time delay for a service request. 

A service request is made by placing an opcode value in the SCA&FO (PG 
SCI opcode) or SCASBJO (BG SCI opcode) field of a terminal's SCA entry 
and executing an Activate Time Delay Task SVC to wake up the BRM. The 
run ID of the BRM task is initialized in byte SCASL2 of the SCA. The 
requesting SCI then enters a time delay loop waiting for the SCA$P0 (or 
SCA$B0) field to clear. 

Background service request opcodes are byte values consisting of two 
hexadecimal digits. The first digit identifies the program that 
processes the request. The second digit specifies a particular 
operation. BRM uses only the first digit to determine the task ID to 
bid. 

Specific opcode values are documented in the QBID and OQUEUE 
descriptions (paragraphs 10. 4 and 10. 5). 
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10.3.3 BACKGROUND COMMUNICATIONS AREA (BCA). 

The BCA consists of two parallel vectors, the TASKID and BUSY 
tables, which are used for communication with the background request 
handler tasks. The first digit of a service request opcode is used to 
index these vectors. The TASKID vector maps the opcode into a DX10 
task bid ID. The BUSY vector informs the BRM whether the indicated 
task/opcode is currently in execution or must be bid to handle the 
request. The BRM sets the busy flag when it successfully bids the 
task. The task resets it when it terminates. 

Entry of each vector is meaningless since an opcode field value of 
indicates no request. 



10.4 QUEUED TASK BID HANDLER (QBID) 

QBID supervises the enqueueing and bidding of background tasks. 
In this context, Background (abbreviated BG) means that a task 
execution is to be initiated at a terminal via the .QBID SCI language 
primitive. Such tasks are then managed by the user indirectly through 
commands that access the QBID program. 

10.4.1 STRUCTURE OE QBID. 

The QBID program consists of three segments. Two shared "dirty" 
procedures, the SCA and BCA, are used for communication with the 
background resource manager and the command interpreter making a QBID 
service request. These procedures are described in the documentation 
for the background resource manager and SCI. 

The task segment of the QBID program consists of several modules which 
contain the QBID code and data. The code is organized as a supervisor 
and four major components. The supervisor executes the four routines 
BOOKIE, POLLER, BIDDER, and WAITER repeatedly until WAITER determines 
that no work remains. 

The bookkeeper routine BOOKIE keeps track of the status of all tasks 
being managed by QBID. Its principal duties are: .Try to remove 
blocks from blocked tasks .Remove queue entries of expired tasks 
.Calculate the current level of background task activity 

Blocked tasks are those that cannot be bid at a particular time but are 
expected to be bidable later. Examples are tasks that are not 
replicable but are currently in execution. Expired tasks are those 
that have been successfully bid and have subsequently terminated. 
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The POLLER routine periodically examines the SCA for QBID service 
request opcodes. Opcodes in the range >10 - >1F are handled 
immediately by invoking the appropriate routine: 



Opcode 

10 
11 
12 
13 



Routine 

BUILDQ 
STATUS 
KILLQT 
DBID 



Purpose 

Build a queue entry 

Check status of queued task 

Kill a queued task 

Bid task in halted state 



The BIDDER routine attempts to bid tasks waiting on the background task 
queue within the constraints of the sysgen-imposed threshold count. 
Tasks are bid only if the current background activity level count is 
not exceeded. Candidate tasks on the queue must not be currently 
executing or marked as blocked. Bid attempts that fail because the 
specified task is not replicable or because the system table area is 
full cause the task to be marked as blocked. 

The WAITER routine decides whether QBID has further work to do. If not 
(i.e., the queue is empty), it informs the BRM via the BUSY vector in 
the BCA that is terminating and does so. If there is more work to do, 
WAITER executes a time delay SVC and exits. The supervisor then 
repeats the execution of the four primary routines. 



Table 10-4 shows the structure of QBID as a table of direct 
calls. 



subroutine 



Table 10-4 QBID Subroutine Call Table 



Calling 
Routine 

QBID 

BIDDER 

BOOKIE 

POLLER 

WAITER 

BUILDQ 

DBID 

KILLQT 

STATUS 

TCASVC 



Routines 
Called 

BIDDER, BOOKIE, POLLER, WAITER 

TSTATE 

BUILDQ , DBID , KILLQT , STATUS 

TCASVC 
BUILDQ 
STATUS 
TSTATE 
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10.4-2 DATA STRUCTURES. 

The following paragraphs describe the data structures used by QBID 
routines. 

10.4.2.1 System Communication Area (SCA). 

The SCA is an area of memory shared as a "dirty" procedure by all 
command interpreters, the BRM, and the background request handlers 
(QBID,OQUEUE) . The SCA contains a table of global system data, such a 
global LUNOs and task bid IDs, plus a table called an SCA entry for 
each terminal that will use SCI990. The SCA is documented in the 
description of SCI990 (see paragraph 10.2). 

10.4.2.2 Background Communication Area (BCA). 

The BCA consists of two parallel vectors, the TASKID and BUSY 
tables, which are used for communications between the BRM, QBID, and 
OQUEUE. The first digit of a service request opcode is used to index 
these vectors. The TASKID vector maps the opcode into a DX10 task bid 
ID. The BUSY vector informs the BRM whether the indicated task/opcode 
is currently in execution or must be bid to handle the request. The 
BRM sets the busy flag when it successfully bids the task. QBID resets 
it when it terminates. 



10.4.2.3 Task Queue Entry. 

Each task to be bid by QBID has an associated queue entry, which 
is created by QBID in its own task area. Each queue entry describes a 
task, information necessary to bid the task, and the current execution 
status. The fields of a queue entry are labeled and defined as 
follows: 

Address of next queue entry 

— QNEXT must be zero — 

Status of queue entry 

Terminal ID 

User ID 

Task bid ID 

LUNO 

Code value 

Task Run ID 

Time place in queue 

Time task was bid 

No. of bytes in a queue entry 



QNEXT 

-X- 


EQU 





QSTAT 


EQU 


2 


QTERM 


EQU 


1 


QUSRID 


EQU 


4 


QBTASK 


EQU 


10 


QLUNO 


EQU 


11 


QCODE 


EQU 


12 


QRTASK 


EQU 


13 


QTIME1 


EQU 


14 


QTIME2 


EQU 


18 


QESIZE 


EQU 


22 
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The status byte (QSTAT) is divided as follows: 

Bit 

1 ** Task has been bid 

1 1 « Task is blocked (task ID in use) 

2 1 * Task is running 
3-7 Reserved 

10.4-3 CALLING SEQUENCE. 

QBID Is always bid by the background resource manager (BRM) task 
in response to a background service request from a terminal command 
interpreter (EG or BG) . SCA opcodes in the range 10 through 1F are 
directed to QBID. The currently defined opcodes are: 

10 Enqueue a background task bid (.QBID) 

1 1 Check status of an enqueued task 

1 2 Kill an enqueued task 

13 Execute a BG task in debug mode (.DBID) 

Associated with these opcodes are fields within the SCA entry that 
specify parameter values. These are: 

SCASBC BG "CODE" Value 

SCA$BL BG Program File LUNO 

SCA$BS BG Status 

SCASBT BG Task ID 

SCA$FE Returned error code (EG) 

SCA$TI Terminal ID 

10.4.4 FILES. 

The only files accessed by the QBID task are the foreground and 
background TCA files, .S$FGTCA and . SSBGTCA, via the LUNOs specified in 
the SCA. When a task is enqueued for BG execution, the FG TCA image 
for the terminal is copied from the FG TCA file to the BG TCA file. 
The TCA image is a single record in each case. The record number is 
the same as the terminal number. The TCA image is "frozen" in this 
manner so that the parameters specified on the corresponding .QBID 
language primitive will be available to the enqueued task when it 
executes. Also, all synonyms defined at the terminal will be available 
to the task. 

The TCA image is described in detail in the SCI990 discussion (see 
paragraph 10.2) 

10.4.5 ERROR CODES. 

The following error codes are returned in the SCA$FE field of the 
SCA entry for the terminal making the QBID request. 
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Code Meaning 



00 No error - request serviced 

01 Unable to allocate a queue entry "block 

02 Unable to access the TCA 

02 BG already pending (should be caught by the 
command interpreter first) 

03 Bid SVC failed for ".DBID" request 
80 Unknown SCA opcode 

FF No queue entry found (Status) 



10.5 QUEUED OUTPUT HANDLER (OQUEUE) 

OQUEUE supervises the enqueuing of files and output to devices and 
of messages to and from terminals. Piles are queued up for output by 
name, rather than by copying the named file to a spooled data area. 
Any number of files may be queued for any number of devices. OQUEUE 
also enqueues messages for transmission to terminals. 

10.5-1 STRUCTURE. 

The OQUEUE program is divided into two tasks, 0Q$C0PY and 0Q$MGR, 
each of which consists of three segments. Both tasks share "dirty" 
procedures, the SCA and BCA which are used for communication with the 
SCI990 task making an OQUEUE service request. These procedures are 
described in the documentation for the background resource manager and 
the command interpreter. 

The task segment of the 0Q$MGR program consists of several modules. 
The code is organized as a supervisor and four major components. The 
supervisor executes the three routines POLLER, BOOKIE, and WAITER 
repeatedly until WAITER determines that no work remains. 

The POLLER routine periodically examines the SCA for OQUEUE service 
request opcodes. Opcodes in the range >20->2F are handled immediately 
by invoking the appropriate routine: 

Purpose 



Opcode 


Routine 


20 


BUILDQ 


21 


STATUS 


22 


KILLDV 


23 


HALT IT 


24 


RESUME 


2E 


SMSG 


2F 


RMSG 



Build a queue entry 
Show output status 
Kill output at a device 
Halt output to a device 
Resume output to a device 
Send a message 
Receive a message 

The bookkeeper routine BOOKIE tracks current I/O and message activity, 
ensuring that each queue entry is ultimately processed. BOOKIE calls 
MBOOKY to check each pending message destination against each currently 
logged-in SCA entry. When a terminal for which a message is pending is 
discovered to be activated, the message pending flag in the background 
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status field (SCA$BS) of the SCA entry is set. BOOKIE then calls 
0B00KY, which attempts to assign an output processor to a file queue 
entry waiting for access to an output device, and assigns an 0Q$C0PY 
task to each device for which output is queued. Thus, queued output 
may "be directed to many devices simultaneously. 

0Q$C0PY is a replicative task that copies files to a device. The file 
and device must have been assigned global LUNOs prior to execution of 

^^ „^v~^^- j.Kj uxu vjj uuc j->\j<jr±j.±j pui uxuu ui u^Jpi'ivjit . ±ntj device 

Status Table (DST) in the BCA contains all the information necessary to 
copy file records to the device. 

The WAITER routine decides whether OQUEUE has further work to do. If 
not (i.e., the queues are empty), it informs the BRM via the BUSY 
vector in the VCA that it is terminating and does so. If there is more 
work to do, WAITER executes a time delay SVC and exits. The amount of 
the time delay is determined dynamically by WAITER. After the time 
delay, WAITER exits. The supervisor then repeats the execution of the 
four primary routines. 

Table 10-5 shows the structure of OQUEUE by its subroutine call 
linkages. 
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Calling 
Routine 

0Q$MGR 
BOOKIE 
POLLER 

WAITER 

MBOOKY 

OBOOKY 

BUILDQ 

HALTIT 

KILLDV 

RESUME 

RMSG 

SMSG 

STATUS 

WRITER 

GETFET 

GETBLK 

GTCA 

S$PARM 

FINDDV 

OPARMS 

S$SETS 

PTCA 

QSOPEN 

Q$WRIT 

Q$WEOL 

WRSTAT 

Q$CLOS 

OPENDV 

OPENPL 

COPYPD 

CLOSE? 

CLOSED 

WSTOP 

TCHELP 

CLRBUE 

SVCSR2 

0PN$R2 

SVC$R1 

FORMAT 

WAIT 



Table 10-5 OQUEUE Subroutine Call Table 

Routines 
Called 



BOOKIE , POLLER , SLICER , WAI TER 

MBOOKY, OBOOKY 

BUILDQ,HALTIT, KILLDV, RESUME, RMSG, SMSG, STATUS 



GETFET 

GETBLK, GTCA, SSPARM 

FINDDV, OPARMS 

PINDDV, OPARMS 

PINDDV, OPARMS 

GTCA, S$SETS, PTCA 

GETBLK, GTCA, SSPARM 

GTCA, S$PARM , Q$OPEN , QSWRIT , Q$WEOL, WRSTAT , QSCLOS 

OPENDV , OPENPL, COPYPD , CLOSEP , CLOSED , WSTOP 



TCHELP 



GTCA.S$PARM 

TCHELP 
CLRBUP 

CLRBUP 
Q$WRIT,Q$WEOL 

SVC$R2,0PN$R2 

SVC&R1 

SVCSR1 , FORMAT , SVC$R2 , 0PN$R2 , WAIT 

SVCSR1 

SVCR2,WAIT 



WAIT 

SVC$R2 

WAIT 
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10.5.2 DATA STRUCTURES. 

The internal data structures used by OQUEUE routines are described 
in the following paragraphs. 

10.5.2.1 System Communication Area (SCA). 

The SCA is an area of memory shared (as a "dirty" procedure) by 
all command interpreters, the BRM, and the background request handlers 
(QBID, OQUEUE). The SCA contains a table of global system data, such 
as global LUNOs and task bid IDs, plus a table called an SCA entry for 
each terminal which may use SCI990 (see paragraph 10.2). 

10.5.2.2 Background Communication Area (BCA). 

The BCA consists of two parallel vectors, the TASKID and BUSY 
tables, which are used for communication between the BRM, OBID, and 
OQUEUE. The first digit of a service request opcode is used to index 
these vectors. The TASKID vector maps the opcode in a DX10 task bit 
ID. The BUSY vector informs the BRM whether the indicated task/opcode 
is currently in execution or must be bid to handle the request. The 
BRM sets the busy flag when it successfully bids the task. OQUEUE 
resets it when it terminates. 

10.5.2.3 Output Queue Entry. 

Each output entry describes a file and a device to which the file 
is to be copied. The fields of the output queue entry are labeled and 
defined as follows: 



QNEXT 


EQU 





QSTAT 


EQU 


2 


QTERM 


EQU 


3 


QUSRID 


EQU 


4 


QTIME1 


EQU 


10 


QTIME2 


EQU 


H 


QDLMAX 


EQU 


18 


QULMAX 


EQU 


18 


QDNLEN 


EQU 


19 


QUILEN 


EQU 


19 


QDVNM 


EQU 


20 


QALMAX 


EQU 


26 


QTLMAX 


EQU 


26 


QANLEN 


EQU 


27 


QMTLEN 


EQU 


27 


QACNM 


EQU 


28 


QASIZE 


EQU 


80 


QDSIZE 


EQU 


6 


QESIZE 


EQU 


QA 
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Address of next queue entry 

— QNEXT must be zero — 

Status of queue entry 

Terminal ID 

User ID 

Time placed in queue 

Time task was bid 

Max length of message name 

Max length of message user ID 

Actual length of device name 

Actual length of message user ID 

Device access name/message user ID 

Max length of access name 

Max length of message text 

Actual length of access name 

Actual length of message text 

Pile access name/message text 



Max No. of bytes in a file name 
Max No. of bytes in device name 
QACNM+QASIZE No. of bytes in queue entry 
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The status byte (QSTAT) is subdivided as follows: 
Bit 




1 
2 

3-7 



1 s Output has begun 
1 as ANSI Format 
1 « I/O completed 
Reserved 



10.5.2.4 File Environment Table. 

A file environment table (FET) is assigned to each output device 
for which files are queued. The FET contains the data specifying the 
file and device, a workspace, and all data and buffers used by a WRITER 
routine to copy records from the file to the device. The FETs and 
WRITER are analogous to DX10 tasks and a shared procedure. The fields 
of a FET are labeled and defined as follows: 

32 BYTE WORKSPACE 

@ NEXT FET IN FET QUEUE 

@ NEXT ENTRY INTO WRITER 

@ INPUT FILE QUEUE ENTRY 

# LINES LEFT ON PAGE 

DEVICE TYPE CODE 

STATUS 

DEVICE NAME 

RETURN STACK 

INPUT PRB 

OUTPUT PRB 

BUFFER 1 

END OF FET 

The FET status byte (WSTAT) is subdivided as follows: 

Bit 


1 
2 
3 
4-7 



WFETRO 


EQU 





WNFET 


EQU 


32 


WPC 


EQU 


34 


WQNTRY 


EQU 


36 


WLINES 


EQU 


38 


WDVTYP 


EQU 


40 


WSTAT 


EQU 


41 


WDEVNM 


EQU 


42 


WSTACK 


EQU 


46 


WPRBI 


EQU 


54 


WPRBO 


EQU 


94 


WBUFF1 


EQU 


134 


WFSIZE 


EQU 


WBUFF1+H0 



1 « Halt output immediately 

1 s Halt output at EOF 

1 « Kill output of current file 

1 s Kill all output at device 

Reserved 



10.5.3 CALLING SEQUENCE. 

OQUEUE is always bid by the background resource manager (BRM) task 
in response to a background service request from a terminal command 
interpreter (FG or BG) . SCA opcodes in the range of >20 through >2F 
are directed to OQUEUE. The currently defined opcodes are: 



>20 
>21 
>22 



Release file to queue 
Show output status 
Kill output to a device 
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>23 Halt output to a device 

>24 Resume output to a device 

>2E Send message 

>2F Receive message 

Associated with these opcodes are fields within the SCA entry that 
specify parameter values. These are: 

SCA$BS BG Status 

SCA$DV Terminal device name 

SCA$FE Returned error code (FG) 

SCA$TI Terminal ID 

SCA$UI User ID 

10.5.4 FILES. 

OQUEUE uses the TCA file and a listing file, as described below. 

10.5.4.1 TCA File. 

The foreground or background TCA file record corresponding to the 

number of the terminal making the OQUEUE service request is read (by 

module OQ$TCA) so that the opcode handling routines can access the 
parameters in the NCT. 

The TCA image is described in detail in the documentation for the 
system command interpreter program, SCI990. 

10.5.4.2 Listing File. 

The Show Output Status function has a listing file as a parameter. 
This listing file is normally the foreground or background terminal 
local file (TLF) , at the option of the SCI PROC which invokes OQUEUE. 
The module OQ$TLF includes the routines used to write to the listing 
file. 



10.5.5 ERROR CODES. 

The following error codes are returned in the SCA$FE field of the SCA 
entry for the terminal making the OQUEUE request. 

Code Meaning 



00 No error - request serviced 

01 No queue block available 
80 Unknown SCA opcode 

FA Invalid argument 

FD NCT error (internal) 

FD TLF Error 

FD TCA error 

FF Queue entry not found 
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APPENDIX A 
SYSTEM CRASH ANALYSIS 



A . 1 GENERAL 

When the DX10 operating system detects a system failure, it displays an 
error code on the front panel lights and idles the CPU, as described in 
the DX10 Operating System Production Operation Manual . The first step 
that must "be taken in order to analyze the system crash is to dump 
memory to the predefined crash file on disk. This is accomplished "by 
pressing the HALT and then the RUN buttons on the front panel. The 
next steps in analyzing the crash are: reboot the system (as explained 
in the DX10 Operating System Production Operation Manual) ; bid SCI at a 
terminal; and 
command. 



execute the crash analyzer, AWALZ , using an XANAL 



A. 2 OPERATING PROCEDURE 

When ANALZ is activated, using the XANAL command, five parameters are 
prompted. The parameters are: 



^LISTING ACCESS NAME: 



^CONTROL ACCESS NAME: the name of the file or 

device from which ANALZ 
expects commands. The default 
is ME. 

the name of the file or 
device to which ANALZ should 
write its output. 

* ANALYZE RUNNING SYSTEM?: answer YES to analyze the 

currently running system, 
(rather than a crash dump). 
If the dump is to be analyzed, 
answer NO. The default is NO. 



*DISK DEVICE NAME: 



*CRASH PILE NAME: 



the name of the disk unit on 
which the crash file is 
written. The default is DS01 . 

the name of the file 
containing the crash dump. 
The default is S$CRASH. 
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If ANALZ is running in batch mode (i.e., a file or sequential input 
device was specified as the control access name), each input value or 
command must start in column one of a separate recor V C f* a^t* Use °J 
batch input to ANALZ allows the user to keep a standard ANALZ command 
stream on file or cards which can be easily and quickly executed after 
every system crash. 



A. 3 COMMANDS 

The commands given to ANALZ cause it to select portions of the memory 
dump on the crash file (or actual memory, if the running system is 
being analyzed) and write them to the listing device in a formatted 
form. Blocks of memory are written eight words per line, proceeded by 
the address of the first word. All numbers are in hexadecimal. An 
abbreviated ASCII representation of the eight words is written to the 
right of the hexadecimal representation. Byte values that do not 
represent a character are written as periods (".")• 

Table A-1 shows the ANALZ commands and the action each performs. 

Table A-1 . ANALZ Commands 
Command Action 



G-I List general information about the crash 
TS List the task states of all currently 

executing tasks 
SS List memory images of the system structures 
MM List a memory map 
AQ List a representation of the four active 

queues 
PQ List a representation of the other system 

queues 
TR List the workspace registers for all tasks 

in memory 
TA List memory images of every task area in 

memory 
AL Do all of the above, in the order given 
DM List a specific area of memory 
DI List disk information 
QU Terminate execution 

Normally, the user needs only execute the AL command to obtain enough 
information about a crash. The following paragraphs describe in more 
detail the results of some of the commands. The commands are described 
in the order in which they are executed by the AL command. Useful 
information is also provided for determining the reason for the crash. 
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A. 3.1 GENERAL INFORMATION (GI) COMMAND. 

The GI command lists general information about the crash. 

A. 3.1 .1 Crash Code. 

The first entry is the system crash code that was displayed on the 

"PlTin'h -nanoT T.rViav\ + Via nwoaU Anniinnnil «-> r-« t.t«1 T ^ r* »> -^ T?-^ ^.T A ^ U 4- -~ ^ *» ~ 1 ~ 4- -S — — 

of the code (see the DX10 Operating System Error Reporting and Recovery 
Manual for a description of the crash codesT^ 

A. 3. 1.2 Executing Task. 

The second entry is the address of the task status block (TSB) of the 
task that was executing when the crash occurred. When this value is 
zero, the crash occurred within the operating system, probably during a 
scheduling cycle. 

A. 3. 1.3 Location of Failure. 

This entry is the address at which the crash routine was called. In 
some cases, this entry points to the exact location of the crash. 
However, in most cases, this value is the location of a common crash 
point that is entered from any of several locations. 

A. 3«1. 4 Status Register. 

This entry lists the value of the status register when the crash 
occurred. The status register information is valuable when the crash 
code is >20. The last four bits (last digit in the entry) of the 
status register is the interrupt mask. When the interrupt mask value 
is in the range >2 - >E, the crash was caused by an illegal interrupt. 
When the interrupt mask value is 1 , the crash was caused by one of the 
task error states occurring within the system or system task. 

A. 3. 1.5 System Variables. 

A set of system variables is printed after the status register value. 
Most of these do not contain useful information. Three of the 
variables may be of some importance. They are: 

MEMSIZ Total amount of memory in the system 
expressed in beets (32-byte blocks). 
This is useful in determining the 
amount of memory space available for 
system and user tasks. 

NUMDEC Negation of the number of time units 
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since the last scheduling action. 
If this number is unusually large, 
a task may be in a loop with the 
scheduler suspended or the scheduler 
itself may be in error. 

RSTRSW Flag that tells if the system has 
completed initialization. If the 
flag is set to -1 (>FFPP), the crash 
occurred because the system was not 
initialized. 
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A. 3. 1.6 Fixed and Runtime Task IDs. 

These entries are "bit maps of all fixed and runtime task IDs. They are 
generally of no value in a crash analysis. 

A. 3. 1.7 System Patch Area. 

A dump of all out-of-line patches that have "been applied to the system 
"by the MEMRES patch file is listed. This is used to verify that all 
out-of-line patches have "been applied to the system successfully. The 
"beginning address of the patch area should "be equal to the value 
assigned to SSPAT. The last five lines of the patch area will give the 
revision letter of the release. The revision letter should he checked 
to make sure that all recent patches have been applied. 

A. 3. 1.8 Monitor Registers and Stack. 

The monitor registers are the registers of the executing task at the 
time of the crash. RO of these registers will often contain the code 
of an error that caused the task to abort the system. The error codes 
are as follows: 

1 Memory Parity Error 

2 Illegal Instruction 

3 TILINE Time Out 

5 Mapping Violation 

A Execute Protect Violation (990/12) 

B Write Protect Violation (990/12) 

C Stack Overflow (990/12) 

D Hardware Breakpoint (990/12) 

E 12 Millisecond Clock (990/12) 

P Arithmetic Overflow (990/12) 

R10 is the stack pointer for the task. A segment of the stack will be 
printed following the workspace registers. The stack pointer can be 
used to trace back through the stack to determine if a lower tier 
routine has passed an error code. 

A. 3. 1.9 Interrupt and XOP Vectors. 

The hardware interrupt and XOP trap vectors should be examined to 
verify that they are intact. Since these values reside in the first 
locations of physical memory, they are often destroyed by a system cr 
privileged task that branches to memory location zero. Usually, the 
locations that are destroyed are locations 0-3 (power-up interrupt) or 
locations 1A-1P (interrupts six and seven). Location is often loaded 
with a bad value when a data word required by a task is not specified. 
Locations 1A-1P are destroyed when a task executes a BLWP instruction 
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to location 0. When the BLWP instruction occurs, the return context of 
the task will he in locations 1A-1E. When a >20 crash occurs, and the 
interrupt mask indicates a defined interrupt (mask value minus one), 
the interrupt trap values should he checked to determine if they are 
within the proper address range. Except for interrupt levels 0, 1, 2, 
and 5, the workspace pointer and program counter for each trap should 
point to about the same locations. 

A. 3. 1.10 Internal Workspaces. 

The last data printed are the workspaces for the clock processor, the 
interrupt 2 processor, and the SVC processor. These routines are 
entered through context switches, so the return context will he found 
in registers R13-R15 of these workspaces. The clock workspace will 
contain the location in the executing task where the last clock 
interrupt occurred. The SVC workspace will contain the location of the 
last supervisor call. These two locations can sometimes help determine 
where a task was at the time of the crash. The interrupt 2 workspace 
contains diagnostic information about a >20 crash. R1 ?-R1 5 contains 
the context of the crash within the system. R1 contains the error code 
(listed above). When looking at the saved status register for 
interrupt 2 (R15), check to see if bit 8 is set or reset. If bit 8 is 
set, the crash occurred in task driven code. If bit 8 is reset, the 
crash occurred in system code. It may be necessary to dump memory 
around the location pointed to by R1 4 to check the listing to determine 
if the code has been modified. 

A. 3- 2 TASK STATE (TS) COMMAND. 

The TS command lists the most commonly referenced terms from the TSBs 
of the tasks in the system. The list contains, for each entry, the 
task ID, the task context at the last time the task was scheduled or 
performed a supervisor call, the current state of the task, the task 
flags, and the TSB address. The task status block list follows the 
listing of commonly referenced terms. The task flags contain useful 
information in bit 5' when this bit is set, the task has been rolled 
out to disk; when this bit is reset, the task is in memory. By 
examining this bit for each task, the user can determine which tasks 
were in memory and may be associated with the crash. 
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A. 3. 3 SYSTEM STRUCTURES (SS) COMMAND. 

The SS command lists the TSB, PSB, PDT, ECB, and LDT information from 
the system. The system templates and/or data structure descriptions 
are helpful when examining the SS command lisitng. 

A. 3. 3.1 Task Status Block (TSB). 

The TSB listing gives the entire TSB for every task in the system. The 
TSB contains all the information about the task that is used "by the 
system. The most important fields in the TSB listing are the end 
action address, the second flag word, the task diagnostic field, and 
the task map file. 

The end action address entry contains the starting address of the 
memory task segment. This parameter is helpful when partial links of 
the system segments are available (provided with DX1 source). By 
taking the end action address entry, and locating where the task 
segment is in one of the partial links, the location of other system 
parts can be found. The length of the root segment can be found from 
the partial links. The starting address of DMGR, which is the start of 
the memory resident task segment, can be located in the TSB listing. 
By subtracting the length of the root segment from the starting address 
of DMGR, the starting address of the root can be determined. The 
starting address of the root segment is useful in determining if the 
crash was caused by DX10. 

The second flag word in the TSBs contains information about the task. 
If the task is being debugged, the first seven bits of the flag word 
contain information regarding the debugger; otherwise the first seven 
bits are set to zero. If the task is suspected as causing the crash, 
the flags should by verified with the templates, and TMRWT and the 
DEBUGGER modules should be examined for possible problems. 

The diagnostic information field in the TSB contains the interrupt 2 
values for a task that has taken end action. This field is helpful 
when analyzing a crash code of >27. The >2 7 crash is caused by TMEXT 
being non-zero when a task is killed. Often this occurs when a system 
task sets TM$EXT to suspend scheduling, then takes end action. Thus, 
even though a task may have a unique crash code, a >27 crash may occur 
because of these circumstances. The diagnostic information contains 
the context vector of the task at the time it was aborted. By taking 
these values, the listings can be examined to determine what conditions 
caused the abort (if the source listings are available). If the 
listings are not available, this information is useful in discovering a 
faulty module, if subsequent crashes occur within the same task area. 
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The task map file is also kept in the TSB. The map file consists of 
three segments, with each segment containing a limit and a base. _ When 
a memory management problem is being considered, or an unexplamable 
map violation occurred from the task, the task map file should be 
examined. To find the upper limit of a task, find the last limit 
register that is not equal to >FFFF and negate it. The task should be 
able to address memory locations up to that point. To check for a 
memory management problem or a TILINE time. out problem, the location of 
each segment in physical memory should be determined. This is done by 
the following formulas: 

Segment Beet Address Beet Length 



1 B1 -11/52 

2 B2+(-Ll/32) (I1-L2)/32 

3 B?+(-L2/32) (I/5-L2)/32 

where the map file -LI, B1 , L2, B2, L3, B3 

The segment beet address can be checked against MEMSIZ (GI command 
listing) to see if the beet address exceeds the memory limit. Also, 
the segment can be checked on the time ordered list (MM command 
listing) if a memory management error is suspected. 

A.5.3.2 Procedure Status Block (PSB). 

The PSB list follows the TSB list. These entries contain the memory 
Beet address and the length of the segment in Beets. It may be 
necessary to verify the procedure locations in memory and check for 
their entry on the time ordered list (MM command listing). The 
procedures have a count of tasks that are attached to them. If the 
procedure is flagged as memory resident, then this count must always be 
at least one. There is no link to the attached task(s) in the PSB; 
this link is maintained by the tasks in the TSB. 

A.3.3.3 Physical Device Tables (PDT) and Device Buffers. 

The next items listed are the PDTs . The PDTs define every device in 
the system. The device buffers are shown with the PDTs; these are 
meaningful only if the device is marked assigned and busy in the PDT 
flag field. The first two words in the PDT contain the PDT link and 
the map file address and are not included in the PDT workspace. If a 
crash occurred when the system was in a DSR, the general location of 
the PC can sometimes be found by looking at the PDT workspace registers 
5 and 6. These registers often contain either the interrupt entry 
vector or a BLWP vector used in the DSR. R5 contains the workspace 
pointer, and R6 contains the program counter. 

All keyboard devices have a keyboard status block (KSB) as the last 
part of the PDT. The KSB contains a ring buffer for the characters 
being input. By looking at this buffer, the last 6 characters input 
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can be determined. Also, the KSB flags contain information about an 
SCI bid and whether SCI is active at the terminal. 

The TILINE and diskette drive PDTs have an extension for each 
controller. The controller can have up to 4 drives associated with it. 
There is one PDT per drive. The extension is found on the first drive 
PDT. The extension indicates the number of drives that the controller 
services. The PDTs for TILINE devices also contain the last TILINE 
image that was sent to or from the device. These parameters are useful 
in isolating disk problems when the crash was related to the disk or 
the crash was forced by the user, when disk activity was 100^ and the 
system was in a "hung" state. 

A. 3. 3. 4 File Control Blocks (FCB). 

The FCB list gives all the files that were assigned at the time of the 
crash. Each disk drive has a list consisting of its VCATALOG entry and 
all the directories and files under it. Each FCB contains information 
the file name, pointers to its parent directory, disk allocation space, 
and logical and physical record sizes. This list is most useful on a 
running system when a drive cannot be released because of LUNO 
assignment. When the FCB LUNO count is zero, the FCB should be 
released. If an FCB is in memory with a LUNO count of zero (see system 
templates), the file is released by assigning a LUNO to that file, and 
then releasing it. This allows FUTIL another chance at removing the 
FCB. A disk will not be released until the only file opened under it 
is VCATALOG. The FCBs are also helpful with FUTIL and file management 
crashes. The FCB list shows all the files in the system at the time of 
the crash. The FCBs can then be examined to determine which file or 
files were involved in the crash. 

A. 3- 3. 5 Disk Partial Bit Maps. 

Each disk that is installed has information concerning its ADU 
allocation printed in the dump. A 3-entry list is given for each 
sector of track that contains disk allocation information. The list 
entries contain the size of the biggest ADU block for each sector, the 
size of the first block, and the size of the last block in that sector. 
There is room in each sector of the bit map to define 2032 ADUs . The 
disk bit map is printed next. Each entry has one word of overhead and 
127 words of bit maps. The allocation information is of little use 
when analyzing a crash; it tells only if the disk is full. 
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A. 3- 3- 6 Logical Device Tables (LDT). 

The last listing printed "by the SS command is the LDT list. The LDTs 
provide information about LUNO assignment in the system. Every task, 
station, and global LUNO is listed, with global LUNOs listed first, 
then station and task LUNOs listed in order of TSB. The LDT contains 
the LUNO number and the pointer to the associated file or device. When 
the LUNO is assigned," the TSB field will contain a non-zero value 
pointing to the TSB that owns the LUNO (see system templates). The 
LDTs are structured as a forward-linked list. The task LUNOs will 
point to the global LUNO list, either directly or through a list of 
task LUNOs. The LDT information is most helpful when using ANALZ on a 
running system. The LDT information can show why a LUNO is not being 
released and what it is pointing to. When examining the listing for a 
particular LUNO, the first LDT with the LUNO desired is looked at 
first. There may be more than one LDT with the same LUNO. The 
information in the first LDT is checked, and if this does not solve the 
problem, the next is examined. The LDT list can also be used in 
diagnosing file utility (PUTIL) problems in a crashed system. 

A. 3. 4 LIST MEMORY MAP (MM) COMMAND. 

The MM command lists information about the system mapping scheme, 
memory within the system table area, memory in the user task area, and 
system overlay segment usage. This set of entries should be examined 
whenever memory management might be involved with a crash. 

A. 3. 4.1 System Memory Maps. 

The system memory maps listing contains the current pointer to the map 
map file, followed by all the system map files defined in the system. 
Each entry in the map file list contains seven words. The first word 
given is the overlay ID of the system image. This should correspond to 
one of the overlay IDs on the link map of the system. (The IDs listed 
in the dump are in hexadecimal, while the IDs in the link map are in 
decimal. This is used only if the link maps of the system are 
available). The remaining six words are the map file registers. These 
are the same as explained for the TSB listing. The first several 
entries are always the same, as follows: 

1 Pile Management and Key Indexed Piles 

2 Memory Resident Tasks 

3 User Common Area 

4 I/O Common Area 

5 Scheduler 

6 Disk Device Service Routine (DSR) 
7+ DSR for Each Remaining Device 

The current map file (CURMAP) pointer is usually pointing to the 
scheduler map" file, entry five in the map file list. When a crash 
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occurs and CURMAP is not pointing to the schedular map file, the 
problem is within one of the DSRs. Whenever a crash occurs and the 
interrupt mask (bits 12-15 of the status register) does not equal >F, 
CURMAP and the map file it points to should be checked. The addresses 
of the device DSR maps are found in the second word of the device PDT. 
When the PDT is dumped, the map file can be verified by checking that 
the second word of the PDT points to one of the listed map files. The 
memory for the DSR is examined by supplying the PDT address (not the 

r T 1 9!"R p /^ /^ T» cms (3 \ -PnT> 4-Viq Tlnwi-n MewftwiT I T)V\ I nftrnmon^ 
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A. 3. 4. 2 System Table Area. 

The system table area contains system usage information and a list of 
available memory. Crashes that are caused by too little table area can 
be determined by looking at the system table header. A >30 crash 
occurs when the system table overflows. The overflow can be determined 
by adding the starting address of the table (located in the header) and 
the total length of the table (also located in the header). If this 
sum is greater than the highest address allocated, a system table 
overflow has occurred. When the system crashes because of a table 
overflow, DX10 should be generated with a larger table area. 

The remainder of the table area defines the free space chain of 
available memory. The header information gives the address of the 
first byte available. The remaining entries give the length of that 
block in bytes and an address pointer to the next available block. The 
list is ended with a zero pointer. 

The system table area contains many structures of 10-100 bytes. When 
the system table area is heavily fragmented and approaching 100^ 
utilization, some devices (such as diskettes) may not be able to obtain 
memory for the device buffer, and cause a table overflow crash. When 
this occurs, the size of the system should be evaluated and resizing 
the system by system generation should be considered. 

Tasks with a coding error can cause a table overflow crash by using an 
unusual amount of table area. When this occurs, the table area listing 
contains many structures of the same type and size. Each entry in the 
system table lists its size in bytes. An example of this type of crash 
occurs when a COBOL program performs record locking on every record of 
a very large (20,000) record file. The system table area will have 
many RTL entries and will overflow. Programs that cause this type of 
crash should be rewritten. 
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A. 3. 4. 3 User Memory Area. 

The user memory area consists of three parts: the user memory header, 
the available memory list, and the time ordered list. All values in 
these tables are given in beets (32-byte blocks). The user memory is 
considered to be all of the physical memory that is not taken up by the 
memory resident segments of the operating system. 

The user area header contains a pointer to the first available block of 
memory, the starting address of user memory, and the total length of 
user memory. No user task can be greater than the total length of 
memory. A crash normally does not occur from this unless the available 
memory space is less than 32K words or >800 beets. Also, no address on 
any of the three lists should be greater than the total length of 
memory (MEMSIZ) . If this occurs, it indicates an error in memory 
management . 

The available space list is a list of the blocks of memory available 
for user programs and their beet lengths. This is a linked list, with 
each entry containing a length word and a pointer to the next available 
block. These entries are kept in the first two words of the first beet 
of the block. 

All user tasks, procedures, and blocking buffers that are not defined 
as memory resident are found on the time ordered list (TOL). Eachof 
these segments have one beet of overhead that links them on the time 
ordered list. The TOL beet contains the block length, the associated 
structure address, the forward link, the backward link, and the segment 
type. Blocks on the TOL are located by looking at the pointers in the 
preceeding or succeeding block, which contain the beet address of the 
desired block. The beet address of each block is not found at the 
front of the entry. 

The TOL is a circular list that is headed by a beet found at the start 
of memory. The segment types are as follows: 

>EFFF Header Entry 

Blocking Buffer 

1 Task Segment 

2 Procedure Segment 

3 Available Block 

The header entry appears first on the list and should not be repeated. 
No buffer on the TOL should have a segment type of three. 

The user area list is useful for diagnosing a crash that was forced, 
due to roll in/roll out deadlocks. Deadlocks can be caused by an area 
of memory being "lost" to the system; i.e., the pointer to a memory 
block may have been accidentally deleted. 

Memory can be verified by checking all memory on the TOL and the 
available space list. Memory is verified by finding the first segment 
of the user area, then adding its length to its starting address to 
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find the second segment. That segment should "be located on either the 
TOL or the available space list. Each segment of memory is then 
checked in similar fashion, until all of the segments are accounted for 
or the missing segment is found. If a segment is missing, this 
indicates a problem in memory management which should be handled by a 
Texas Instruments representative. When checking -the available memory 
list, care must be exersized when the task loader was active at the 
time of the crash. The loader may have been in the process of 
delinking a block of memory. 

Anytime an entry or pointer in the lists is greater than MEMSIZ, the 
entry is in error. This is usually caused by memory management 
allocating a second block of memory over the top of the first block 
allocated. The segment that overwrote the first should be examined for 
conditions that would cause memory management to put that segment at 
that location in memory. 

NOTE 

Do not try to look at the TOL on an active system. 
The memory chain will change while ANALZ is 
scanning the list, causing ANALZ to print 
meaningless data. 



A.3-4-4 System Overlay Areas. 

The system overlay area information gives the address of each overlay 
area, the status of the area, and the overlay ID. This listing is 
useful only if the crash occurred when the system was executing in one 
of the overlays. When the crash occurs in an overlay, this area is 
used to find the overlay. The system listings indicate the correct 
code that should be in the overlay area. 

A. 3. 5 LIST QUEUES (AQ and PQ) COMMAND. 

The AQ command is used to list the four active queues of the system. 
The PQ command is used to list other queues in the system. The active 
queues show the tasks queued for execution at the four priority levels 
of the system. The other queues include the file utility queue 
(PUTIL), the waiting on memory queue, the system log queue, and the 
device queues. These queues may be of importance during a system 
crash. 

The queues listed by the PQ commands should not have more than three 
entries, except for the waiting on memory queue, where the length of 
the queue is a factor of system load versus system memory. When a 
queue is found to be unusually long, the queue processor should be 
checked to see if it is still active and the state it is in. 
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A. 3- 5-1 PUTIL Queue. 

The file utility routine (PUTIL) services all create file functions and 
all assign LUNO functions to files and devices. The PUTIL queue is 
sometimes large because of the type of operation it is performing, such 
as creating large key index files. The queue processor should be 
checked when this occurs. Sometimes the PUTIL queue and processor will 
be blocked when performing I/O to a device. Some devices, such as line 
printers, have a long time-out associated with them. When the device 
is offline, and PUTIL is trying to assign a LUNO to the device, PUTIL 
is suspended until the time-out is performed. During that time, no 
other entry on the PUTIL queue can be serviced. Users may force a 
crash when this occurs, because it appears that the system is in a roll 
in/roll out deadlock. Some crashes are caused by a PUTIL roll in/roll 
out deadlock. Sometimes PUTIL will be rolled out of memory with a 
longer than average queue, and will not be able to obtain memory for 
roll in. When this occurs, it must be determined why PUTIL cannot get 
memory and what routine is supposed to handle that condition. The 
listings of the task loader area should contain the routine that 
handles PUTIL memory management. 

A.3.5.2 Waiting on Memory Queue. 

The waiting on memory queue contains the task status blocks (TSBs) of 
all tasks that are ready to execute but need memory. This queue grows 
in proportion to the number of tasks that are in the system and the 
size of available memory. There are times when no task is executing, 
and every task is on this queue. When this happens, the system 
deadlocks and crashes are usually forced. Conditions that lead to this 
are when tasks lock other tasks into memory without following the rules 
of the operating system. The most common occurrence of this is when a 
device tries to simulate TILINE I/O, which locks a task into memory, 
and the task does not set the supervisor control block (SCB) flag when 
the I/O completes. The SCB flag indicates to the system schedular that 
end-of-record processing must be performed, and that the task can be 
rolled out of memory. When this flag is not set, there is the 
possibility that the roll out algorithm will be caught in an endless 
loop. Other situations that lock tasks into memory and cause deadlocks 
are file management requests and alternate TSB servers. 

Another situation that causes the waiting for memory queue to grow, and 
causes system deadlocks, is problems with the system disk. Sometimes 
the disk will go offline and roll in/roll out cannot be performed. The 
system log and system log queue should contain error messages when the 
system disk is in question. 

. A.3-5-3 System Log Queue. 

The system log queue contains all the system log messages that are 
waiting to be written to the system log device. System log messages 
will be kept on the queue if the system log device has not been 
initialized or if the queue is getting more messages than the system 
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log device can handle. In this second case, the messages on the queue 
will often give a clue as to what went wrong with the system "before the 
crash occurred (for example, when there are problems with the system 
disk) . 

A. 3-5-4 Device Queues. 

Each device has a n ueue list anchored in the PDT» This n ueue is a list 
of I/O requests made to that device. When a particular device is off- 
line or down, and the device has no time out value, the list may become 
long. When a crash is forced "because a task would not come hack from 
an I/O request, the device queues should be checked for the task 
requesting I/O and for unusual queue length. The system templates 
indicate where the queue pointer is in the PDT. 

A. 3- 6 TASK REGISTERS (TR) COMMAND. 

The TR command lists all of the workspace registers of the tasks that 
are in memory at the time of the crash. Workspace registers 10 and 11 
are useful in determining where the task was executing at the time of 
the crash. Registers 10 and 11 give the stack location for the task 
and where the last return from a branch and link (T3L) was in the task. 
These registers are used with the task listing to locate where the task 
was executing, and the data structures it was executing on. Register 
10 points to the area containing information on routines called and 
parameters passed to them. 

A. 3- 7 TASK AREA (TA) COMMAND. 

The TA command lists two parts of memory: the task memory area and the 
system data base. 
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A. 3. 7.1 Task Area. 

The task area listing shows the raw memory dumps of the task segments. 
The procedure segments are not shown; these must be listed with the 
dump memory (DM) command. The push/pop stack is usually kept in the 
task segment and will be listed by this command when it is. Many times 
it is necessary to determine if the task memory space has been altered. 
By checking the task area with a listing of the task, it can be 
determined if any task memory has been wiped out. If several words 
have been destroyed, it may be possible to determine which processor 
wiped out the code and what type of operation was being performed. 
Pile management and TILINE data transfers often cause destroyed code. 
By checking the SVC call blocks, the buffer areas of the transfer can 
be determined. An incorrect address in the SCBs will cause code to be 
wiped out. Another cause of destroyed code is caused by the TILINE 
device service routine not getting the right physical address of the 
output buffer. Common places where this is discovered is in the first 
100 words of the system, or at addresses greater than >C000. The 
device service routines may have bugs when this occurs. 

A.3-7.2 System Memory. 

This listing is a dump of the system data base. This area is the first 
module of the operating system, with the largest part being the system 
table area. It is often necessary to examine data structures that are 
not listed in the above sections of the ANALZ dump, but are found in 
the system table area. Sometimes the table area is modified, similar 
to the modifications of the task area listed above. This part of the 
dump is important, because it lists the system data base without being 
restrained to data structures. 

A. 3. 8 ALL (AL) COMMAND. 

The AL command allows the user to do all of the functions listed above, 
in the order given, with one command. This is the most useful way of 
performing a crash dump analysis. It allows for easy referencing 
between different parts of the system without having to enter separate 
commands for each part to be analyzed. Two other commands are 
available for the analysis; these are listed below. 

A. 3- 9 DUMP MEMORY (DM) COMMAND. 

The DM command is used to list memory not shown by any of the above 
commands. The DM command can be used in three ways. The first is to 
give a task status block address and a relative address within the 
task. This gives a list of the task area not given by one of the above 
commands. The second method is is to give the address of one of the 
physical device tables for the device. This gives the memory available 
for the DSR. This second method also allows for the viewing the system 
root and I/O common area. The third method is to list absolute memory. 
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This requires a TSB address of zero, and a 21 "bit absolute address. 
This method should he used when examining the time ordered list memory 
(i.e., the memory pointed to by entries on the time ordered list). 

A. 3- 10 DISK INFORMATION (Dl) COMMAND. 

The DI command provides information on each file and directory of the 
system disk. This command is rarely used in a crash analysis. The 
information given by the DI command, for each file, is a follows: 

* Pile Name: the name of the file. 

* LRL: the logical record length of the file. 

* PRL: the physical record length of the file. 

* Size: the number of ADUs in the file. 

* Address: the starting ADU address of the file. 

* Logical EDM: the logical end of file address. 

* Block EDM: the physical end of file address. 



A. 4 ANALYZING >20 AND >2^ CRASHES 

The most common types of crashes are >20 and >2 r? crashes. The 
following paragraphs give suggestions on how to start analyzing these 
crashes and what conditions to look for. 

A. 4.1 >20 CRASHES. 

The >20 crash is caused by an illegal internal interrupt. In most 
cases it is an error interrupt within the system. The following steps 
indicate what should be looked for when a >20 crash occurs. 

A. 4« 1.1 Status Register. 

When a >20 crash occurs, the status register should be checked first. 
If the last 4 bits of the status register do not equal one, the crash 
is caused by an illegal internal interrupt. This indicates that a 
device interrupted at an interrupt level that is not defined, or that a 
device interrupted within an expansion chassis and the device position 
in that expansion chassis is not defined. The value of status register 
bits 12 through 15 plus one indicate the interrupt level that was 
taken. The hardware configuration and the system generation listing 
should be checked to determine if the interrupt level taken is a legal 
interrupt. If the interrupt is legal, then the interrupt workspace is 
checked for a bad chassis position interrupt. A pointer to that 
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workspace is at the "beginning of memory at location interrupt level 
times four. Workspace register 9 will have the position value times 8 
that caused the the interrupt. Divide the contents of R9 by eight, and 
check the hardware configuration to verify the chassis position. 

A. 4. 1.2 Interrupt Two Workspace. 

In most cases, the status will be >C001 . This indicates a task error 
within the operating system. In the error interrupt workspace, 
register 1 will contain the task error code that caused the crash. 
These error codes are listed above under the description of the level 2 
workspace. When the error code is found, the contents of registers 1% 
14, and 15 show the location of the crash, and the status at the time 
of the crash. If bit 8 of workspace register 15 is set to one, the 
crash occurred in a user task; if it is set to zero, the crash occurred 
in a system task. The contents of register 14 is the program counter 
at the time of the crash. This code around this location should 
indicate what caused the crash. The workspace pointer is in register 
13; the task workspace is used to check indexed addresses. The task 
listing should be consulted to determine what instructions were being 
executed at the time of the crash. 

A. 4. 2 >27 CRASHES. 

The >27 crash is the same as a >20 crash, except that the crash occurs 
within a system task. The definition of a >2^ crash is "TM$EXT non- 
zero during kill task", which is caused by a task taking end action 
while it has suspended the scheduler. The crash occurs before the end 
action is taken. When this crash occurs, the value of ETSK shows the 
executing task at the time of the crash. The TSB for this task (found 
in the TSB list) has a diagnostic information field containing the 
error code and the context of the task at the time of the area. With 
this information, the >27 crash is handled the same as the >20 crash. 
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APPENDIX B 
REGENERATING DX10, SCI, SDSMAC, * XLE PROM SOURCE 



B.1 GENERAL INFORMATION 

A DXIO Release 3-2 (or later) system with FORTRAN installed must 
be used when it is desirable to regenerate DX10. Because of the large 
volume of data required, the regeneration process normally requires a 
4-disk system to complete the process. The disks required are: 

System disk — Contains a DX10 system, 5000 contiguous 

sections of temporary space, and the 
FORTRAN compiler and runtime package. 

Source disk — Contains source and object files. 

Listings disk — Contains the source listings. 

Build disk == Disk onto which to build the new system. 

Batch listings disk — Contains the batch execution listings. 

Not necessarily a different disk. 

The system disk must be a DS10 or larger disk. The source disk must be 
a DS25 or larger disk (64176 sectors required). 

The listings disk must be larger than a DS25 to contain all the source 
listings^ (102543 sectors required). The assemblies may be done so that 
the listing disk capacity requirement may be reduced by changing the 
disk during the course of the assemblies. It is recommended that a 
DS25 disk be the minimum capacity disk used. The additional files for 
the microfiche require an additional 6624 sectors for a total of 109167 
sectors. 

The batch execution listings disk may be a DS31 or larger disk. The 
batch listings require 5082 sectors. These listings may go to the 
system disk, the listngs disk, or any other disk ' in the system 
(excluding the source disk). 

A single magnetic tape drive is required if the magnetic tape disk 
build media is to be done. 

To execute the batch stream named VOLSRC .BATCH. LINKBLD, the user must 
have a privilege code of 6 or 7. 
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B.2 ASSEMBLING AND COMPILING DX10 

The DX10 source is logically divided into directories according to 
operating system function. These directories are described in this 
system design document. A batch stream is supplied for each operating 
system directory that will perform the conversion of source to object. 
These batch streams recompile or reassemble all source modules if the 
proper synonyms are correctly assigned. The required synonyms are: 



Synonym 

VOLSRC 
VOLOBJ 
VOLLST 
YOLSYS 
V0L$$BAT 



Value 



SYSBLD (volume name of source disk) 

SYSBLD (volume name of object disk) 

LIST3X (volume name of listing disk) 

?????? (volume name of executing system disk) 

LIST3X (volume name of batch listings disk) 



The source disk supplied by Texas Instruments is named SYSBLD. 
Normally, the listing disk contains the release level in the volume 
name when the procedure is executed by Texas Instruments personnel. 
The names have been LIST30 for Release 3-0 and LIST31 for Release ?.1. 
The name may be changed without impacting the procedure. 

The following is a list of the batch streams to reassemble/compile 
DX10: 

SYSBLD . BATCH . ASM . ANALYZ 

SYSBLD . BATCH . ASM . DEBUGR 

SYSBLD .BATCH . ASM . DEVDSR 

SYSBLD . BATCH . ASM . DSCBLD 

SYSBLD . BATCH . ASM . DSCMGR 

SYSBLD .BATCH . ASM . DX1 

SYSBLD . BATCH . ASM . DXMISC 

SYSBLD. BATCH. ASM. DXUTIL 

SYSBLD . BATCH . ASM . PILMGR 

SYSBLD . BATCH . ASM . FUTIL 

SYSBLD . BATCH . ASM . GEN9Q0 

SYSBLD .BATCH . ASM . KIEILE 

SYSBLD . BATCH . ASM . MEMMGR 

SYSBLD . BATCH . ASM . NOSHI P 

SYSBLD . BATCH . ASM . PGPILE 

SYSBLD . BATCH . ASM . SYSTSK 

SYSBLD. BATCH. ASM. TSKMGR 

SYSBLD . BATCH . ASM . UTCOMM 

SYSBLD . BATCH . ASM . UTDIRP 

SYSBLD . BATCH . ASM . TJTDXTX 

SYSBLD . BATCH . ASM . UTGENR 

SYSBLD . BATCH . ASM . UTSVC 



Assign the synonyms and execute each of the batch streams with the XB 
command. The approximate run time is 13 hours. 
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B.3 ASSEMBLING SCI990 

To assemble SCI990, execute the following batch stream with the 
same synonyms assigned as required for DX10 reassemblies: 

SYSBLD.SCI990. BATCH. ASM 

This bfltoh Rtrpam runs QnnrrtYima+aliT "K OC V>«n-«e. 

B.4 ASSEMBLING SDSMAC 

To assemble SDSMAC, execute the following batch stream with the 
same synonyms assigned as required for DX10 reassemblies: 

SYSBLD . SDSMAC . BATCH . ASM 
This batch stream runs approximately 2.5 hours. 

B.5 TRANSLITERATING THE LINK EDITOR 

To transliterate the link editor, execute the batch stream named: 
SYSBLD. LINKER. UTILITY. INSTALL. 

This installs the transliterator required to translate and assemble the 
link editor source. Use the same synonyms assigned for DX10 
reassemblies. When this batch stream has completed, execute the batch 
stream named: 

SYSBLD . LINKER . BATCH . ASM 
This batch stream runs approximately 2.2 hours. 

B.6 LINK EDITING DX1 

Assign the following synonyms and then execute the following batch 
streams: 

Synonym Value 



VOLSRC SYSBLD (volume name of source disk) 

VOLOBJ SYSBLD (volume name of object disk) 

VOLBLD REL32 (volume name of disk to build) 

YOLSYS ?????? (volume name of executing disk) 

V0L$$BAT LIST3X (volume name of batch listings disk) 
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Batch Stream 

SYSBLD . BATCH . DXLINKS 
SYSBLD . BATCH . UTLINKS 
SYSBLD . BATCH . GENPARTS 
SYSBLD . SC 1990 . BATCH . LINK 
SYSBLD . SDSMAC .BATCH . LINK 
SYSBLD . LINKER . BATCH . LINK 



Function 

Pre-links and links of DX10 parts 
Pre-links and links of all utilities 
Compress object for SYSGEN parts 
Link of command interpreter parts 
Link of macro assembler 
Link of link editor 



'he approximate run time is 2.9 hours. 



B.7 BUILDING THE DX1 SYSTEM DISK 

Install a new disk in drive DSO? (must be DSO'3 for MVI commands). 
Initialize the volume using the INV command and the following 
responses : 



[] INV 

INITIALIZE NEW VOLUME 

UNIT NAME 

VOLUME NAME 

NUMBER OE VCATALOG ENTRIES 

BAD TRACK ACCESS NAME: 



DSO^ 

REL33 

100 (DS-52), 200 (DS10), 

342 (DS25, DS50) 

DUMY 



NOTE 

If drive DS03 is not available for this purpose, it 
may be changed but with difficulty. One must text 
edit a file on the master source disk to change the 
operand for the disk drive for the MVI command. 
The file pathname is SYSBLD. MVI CONT. The first 
line of the file contains the entry DS03 that must 
be changed to the name of the available drive. 
This change and changing the operand for the drive 
response of the INV command above are the only 
changes required. Proceed with caution since the 
master disk must be written to when QUITING the 
edit session. 
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Assign the synonyms as described for the links and execute the 
following batch streams: 

Batch Stream Function 



SYSBLD. BATCH. BLDX10 Build the new DX10 system disk 

SYSBLD.SCI990. BATCH. SCI990 Install the command interpreter 

SYSBLD. BATCH. PROCO Install SCI procedures (level 0) 

c«vc«"RT.n ■nArppTT vonno T ro +«-ii qpt rM. nna ^ir. Q o fi^rpi o} 

SYSBLD. BATCH. PR0C4 Install SCI procedures (level 4) 

SYSBLD. BATCH. PROC 6 Install SCI procedures (level 6) 

SYSBLD. BATCH. MENU Install the SCI procedure menus 

SYSBLD. BATCH. SDSMAC Install the macro assembler 

SYSBLD. LINKER. BATCH. INSTALL Install the link editor 

SYSBLD. BATCH. PROTCT Delete protect the system tasks 

The approximate time is 1.1 hours. 

Patch the system just built by copying and editing the file named 
REL33- PATCH. MEMRES. The instructions for editing the file are 
contained in the first few lines of the file itself. Use the 
Copy/Concatenate utility to copy the file: 

[]CC 
COPY/CONCATENATE 

INPUT ACCESS NAME(S): REL3 3, PATCH. MEMRES 

OUTPUT ACCESS NAME: REL33- PATCH. XMEMRES 

REPLACE?: NO 

MAXIMUM RECORD LENGTH: 80 

Edit the file named REL33. PATCH. XMEMRES to assign the required 
synonyms. The link map for the built system is in the file named 
VOLOBJ.DXLINK.MAP.S$IMAGES. Assign the synonym $$DSC$ to the value 
REL33 and execute the batch stream named REL33- PATCH. XMEMRES. The 
runtime is approximately 5 minutes. 

Execute the batch stream named REL33. PATCH. PROGA to patch the system 
program file. This takes about 5 minutes. 
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B.8 BUILDING THE DX1 DISK BUILD MAGNETIC TAPES 

To make the magnetic tapes for the magnetic tape disk build 
procedure, follow the instructions listed below. The synonyms assigned 
are to be used during the entire process. Three magnetic tapes are 
made requiring the following resources: 

System Disk — Contains system and temporary space. 

Source Disk — Contains source, object, and batch 

streams (SYSBLD). 

Built DX10 System — Contains a DX10 system as the result of 

the preceding procedure for building the 
DX10 system disk. 

Assign the following synonyms: 
Synonym Value 



DSC SYSBLD 

DSC2 REL33 (new DX10 system disk) 

*For Tape 1: .Mount a 1200-foot magnetic tape in drive one (MT01 ) with 
a write-enable ring installed. Then, execute the batch stream named 
SYSBLD. BATCH. BST1 . The approximate runtime is 25 minutes. 

*For Tape 2: .Mount a second 1200-foot magnetic tape in drive one 
(MT01 ) with a write-enable ring installed and execute the batch stream 
named SYSBLD. BATCH. BST2. The approximate runtime is one minute. 

*Eor Tape 3: .Mount a third 1200-foot magnetic tape in drive one 
(MT01 ) with a write-enable ring installed and execute the batch stream 
named SYSBLD. BATCH. BST3 • The approximate runtime is 10 minutes. 
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APPENDIX C 
SCHEDULER STRUCTURE AND OPERATION 



C.1 PLOW OP CONTROL POR DX10 SCHEDULER 

The following list is a detailed flow of control for the DX10 task 
scheduler. The scheduler is entered when one of the following five 
conditions is met: 

* When the executing task suspends. 

* When a time delay task is due to become active. 

* When a task time slices out (if time slicing is enabled). 

* When a device service routine (DSR) bids a task. 

* When the task sentry decides to lower the priority of the 
executing task. 

The scheduler is entered from the routine named TRAPRT, which is the 
common exit point for X0PRT2, X0PRT3, TMSDEC, and TM$CLR. The 
scheduler will not be entered if the scheduler inhibit flag (TM$EXT) is 
high, if the time slice extended flag (TMESLC) is non-zero, or if the 
previously executing task was in map file 0. 

The variable ETSK is a word in the root of DX10 that points to the TSB 
of the currently executing task. When no task is executing, ETSK is 
null. 

The flow of control for the task scheduler is given in the steps that 
follow. 

0.0 MAIN ENTRY POINT (defined as SLCSUS) 

1 . ETSK NULL? 

If ETSK points to a TSB when the scheduler is entered, 
then either this task was time sliced out, a device 
service routine (DSR) bid a task, a time delay task was 
due to become active, or the task sentry decided to 
lower this task's priority. 

YES - GO TO 3.0 



939153-9701 C-1 Texas Instruments 



Scheduler Structure and Operation System Design Document 



2.0 Put the TSB pointed to by ETSK on the active queue, 
task sentry for CPU-bound tasks, and 
set ETSK to zero. 



3.0 CLEAR: 

These flags are cleared each scheduling cycle: 
Time slice ended flag (TMSDFR); 
Scheduler inhibit flag (TM$EXT); 
Time slice extended flag (TMESLC). 

4.0 UPDATE TIME AND DATE 

The number of elapsed system time units is added to the 
computer clock calendar. 

5.0 UPDATE TIME DELAY TASKS 

Time delay tasks also are updated by the number of 
elapsed system units. If the task is due to become 
active, the scheduler puts it in an active status. 

6.0 HAS A SYSTEM TIME UNIT ELAPSED? 

The timeout logic for device service routines should be 
entered at 50 millisecond intervals; i.e., each system 
time unit. 

YES - 00 TO 8.0 

7.0 HAS A DSR BID UP A TASK? 

If a DSR bids a task, then the global variable BIDTSK is 
non-zero. If this is the case, the DSR timeout must be 
entered now. 

NO — GO TO 9.0 

8.0 CHECK REENTER-ME AND TIMEOUTS FOR PDTS (BLWP TMOUT) 

9.0 IS TILINE END OF RECORD OUTSTANDING? 

Since tasks that do TILINE I/O are locked into memory, 
do a TILINE end of record as soon as posible to allow 
the task to be rolled. If TILINE EOR is outstanding, 
the global variable SCB is non-zero. 

YES — GO TO 24-5 

10.0 IS ACTIVE QUEUE EMPTY? 
YES — GO TO 13-0 
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11.0 GET HIGHEST PRIORITY TASK OPE ACTIVE QUEUE; 

SET ETSK TO PONT TO TSB OP HIGHEST PRIORITY TASK. 

12.0 IS ETSK A REAL TIME OR SYSTEM PRIORITY? 

If a real time or system task wants to execute, the 
scheduler does not attempt to service SCI "bids during 
this scheduling cycle. 

YES — GO TO 19.0 

13.0 IS RESTART IN PROGRESS? 

No SCI "bids are serviced until the system restart task 
has initialized the system. 

YES — GO TO 15.0 

14.0 SCAN KSBs FOR SCI BIDS 

The scheduler bids SCI for each KSB that requests it 
using the routine named TMBIDO. 

15.0 HAS A TASK BEEN SELECTED (Is ETGK not null)? 
YES — GO TO 19.0 

16.0 IS TASK LOAD IN PROGRESS (TMMLIP not null)? 

If the scheduler has previously requested a task to he 
rolled in, there is no need to try to roll in another 
task. 

YES — GO TO 18.0 

17.0 IS ANY TASK WAITING ON MEMORY (TMWOMO not null)? 
YES — GO TO 21 .0 

18.0 GO IDLE (wait for interrupt). 
GO TO 3.0 

19.0 IS THERE AN ALTERNATE TSB FOR ETSK? 
YES — GO TO 22.0 

20.0 SHOULD A TASK WAITING ON MEMORY BE LOADED? 

If a task waiting on memory is of higher priority or 
equal priority and ETSK has had a minimum number of time 
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slices, if time slicing is available, then the task 
loader is given the CPU to load the waiting task. 

NO — GO TO 22.0 

21.0 REQUEUE ETSK ON ACTIVE QUEUE IP NOT NULL; 
SET ETSK TO POINT TO TASK LOADER TSB; 
SET TMMLIP TO NONZERO (SIGNAL LOAD IN PROGRESS). 

22.0 SET TIME SLICE COUNT 

Initialize the number of clock ticks for a time slice. 
If time slicing is disabled, a non-zero number is used 
here. 

23.0 IS END OP RECORD OUTSTANDING FOR ETSK? 

Since TILINE EOR was checked earlier, this is a check 
for CRU I/O. 

NO — GO TO 25.0 

24.0 REQUEUE ETSK ON THE ACTIVE QUEUE 

24.5 SET ETSK TO POINT TO DEVICE DRIVER TASK; 
GO TO 34.0 

25.0 IS THERE ANY ALTERNATE TSB PRESENT POR ETSK? 
NO — GO TO 27-0 

26.0 SET ETSK TO POINT TO ALTERNATE TSB; 
GO TO 34.0 

27.0 IS THIS TASK QUIETING? 

Tasks that are quieting have been selected to be rolled 
and are kept on the active queue until their I/O is 
finished. 

NO — GO TO 30.0 

28.0 IS I/O IN PROGRESS? 
YES — GO TO 2.0 
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29-0 PUT ETSK ON QUIET QUEUE; 

The task loader is a dedicated queue server of the quiet 
queue and will "be activated when something is placed on 
its queue. 
CLEAR ETSK; 

GO TO 3.0 

30.0 IS LEAVE ALONG FLAG SET FOR ETSK? 
YES — GO TO 34.0 

31.0 IS ABORT FLAG SET? 
NO — GO TO 34.0 

32.0 IS I/O COMPLETE? 
HO — GO TO 2.0 

33-0 BRANCH TO END ACTION 

34.0 PROCESS GET CHARACTER SVC 

The processing necessary for the get character SVC is 
small and the SVC overhead is saved "by moving the 
character from the TSB, placed there by the DSR, to task 
register 0. 

35.0 DOES AN OVERLAY NEED TO BE READ IN FOR ETSK? 
NO — GO TO 37-0 

36.0 PLACE ETSK ON OVERLAY LOADER QUEUE; 
GO TO 3-0 

37.0 IS ETSK UNDER CONTROL? 

This is a flag set in the TSB. 

NO — GO TO 39.0 

38.0 PLACE ETSK IN STATE 6; 

Task suspended by the scheduler. 
CLEAR ETSK; 

GO TO 2.0 
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39-0 SET UP TASK FOR EXECUTION 
Set task in state 7; 
Increment loader roll count (TSBT1); 

Put task memory on time ordered list (if not memory resi 
dent) 

40.0 GIVE CONTROL TO ETSK VIA A RTWP USING PC, WS, AND 
STATUS IN THE TSB POINTED TO BY ETSK. 



C.2 PREEMPTIVE EXECUTION 

Task scheduler operation is based on the concept of preemptive 
execution. Preemptive execution allows a higher priority task to have 
the CPU whenever it becomes active. Eor example, if task T1 with a 
priority of R5 is executing, and a task T2 of priority R2 is bid, T1 is 
suspended and T2 is placed in execution. If task T3 of priority RO is 
subsequently bid, T2 is suspended and T3 is put into execution. 
Preemption is shown in figure C-1 . 



Time 

ms. 
30 ms. T2 prempts T1 
50 ms. 



Task in 
Execution 

T1 
T2 
T2 



Active 
Task Queue 

T1/R5 

T2/R2,T1 ,R5 
T2/R2,T1 ,R5 



Action 

T2 is bid 



750 ms. T2 

783 ms. T3 prempts T2 T3 

800 ms. T3 

841 ms. T2 

850 ms. T2 



T2/R2,T1/R5 
TVR1 ,T2/R2,T1/R5 
T?/R1 ,T2/R2,T1 ,R5 
T2/R2,T1/R5 

T2/R2,T1/R5 



T3 is bid 

T3 has 
completed 



T1 - has an assigned priority of R5 
T2 - has an assigned priority of R2 
T3 - has an assigned priority of R1 



Figure C-1 Preemption 



C3 TIME SLICING 

Time slicing is a task scheduler option that can be selected at system 
generation (sysgen) time. Also specified at sysgen is the length of 
the time slice. This is defined as a multiple of system time units (at 
50 milliseconds each) . The default parameters are to have time 
slicing, with each time slice is to be one system time unit (50 
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milliseconds). When time slicing is invoked, the time slice value is 
the amount of CPU time that is given a task each time it executes, and 
the next task to execute is the next task of the same priority. (This 
is somewhat different from the pre-DX10 3. 2/TX2.3/TX5 task scheduler as 
this scheduler only slices tasks of 

is the only task running. If task T5, priority R2, is bid, followed 
shortly by task T6, priority R2, then T5, and T6 will alternate running 
for 50 millisecond time slices. When both have completed, task T4 is 
allowed to execute again. This is shown in figure C-2. 



T5 prempts T4 



Time 

ms. 
50 ms . 
100 ms. 
128 ms. 
150 ms. 
183 ms. 
200 ms. 
250 ms. 
300 ms. 
350 ms. 
400 ms. 

450 ms. 
500 ms. 
540 ms. 

550 ms. 
600 ms. 
650 ms. 
700 ms. 
717 ms. 
750 ms. 
800 ms. 
850 ms. 
852 ms. 
900 ms. 
950 ms. 



T4 - has an assigned priority of R5. 
T5 - has an assigned priority of R2. 
T6 - has an assigned priority of R2. 
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Execution 


Task Queue 


T4 


T4/R5 


T4 


T4/R5 


T4 


T4/R5 


T5 


T5/R2,T4/R5 


T5 


T5/R2,T4/R5 


T5 


T5/R2,T6/R2,T4/R5 


T6 


T6/R2,T5/R2,T4/R5 


T6 


T5/R2,T6/R2,T4/R5 


T6 


T6/R2,T5/R2,T4/R5 


T5 


T5/R2,T6/R2,T4/R5 


T6 


T6/R2,T4/R5 


T6 


T6/R2,T4/R5 


T6 


T6/R2,T4/R5 


T6 


T6/R2,T5/R2,T4/R5 


T5 


T5/R2,T6/R2,T4/R5 


T6 


T6/R2,T5/R2,T4/R5 


T5 


T5/R2,T6/R2,T4/R5 


T6 


T6/R2,T5/R2,T4/R5 


T5 


T5/R2,T4/R5 


T5 


T5/R2,T4/R^ 


T5 


T5/R2,T4/R5 


T5 


T5/R2,T4/R5 


T5 


T4/R5 


T4 


T4/R5 


T4 


T4/R5 



Action 

Task T5 is bid 
Task T6 is bid 



T5 suspends for 

1/0 ' 



T5 completes 
I/O 



T6 terminates 



T5 terminates 



Figure C-2 Time Slicing 
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C4 TASK SENTRY 

Task sentry is the other scheduler option that can "be selected at 
sysgen time. Also defined at sysgen is the task sentry value 
(expressed in multiples of system time units), if the task sentry is to 
be used. The sysgen default parameters are not to have task sentry 
selected, but if task sentry is selected, the default time value is 60 
system time units (three seconds). When task sentry is operational the 
operating system determines which task is running at the end of each 
system time unit. If the same task is running now as was running at 
the last check, an elapsed time counter is decremented. If a different 
task is running, then the elapsed time counter is reset to the task 
sentry value specified at sysgen. If the elapsed time counter reaches 
zero, the task in execution is lowered to the next lower priority value 
and placed at the bottom of the list for that priority level. The 
elapsed time counter is then reset, and the top task on the active 
queue is placed in execution. If task sentry places a task on a 
populated list, then the task is returned to its loaded priority level 
when it is next allowed to execute (i.e., task sentry cannot reduce a 
task priority below that of the next lower priority task in the 
system). Likewise, if a task terminates or suspends for any reason, 
its priority is reset to that the priority assigned to it when it was 
loaded. Figure C-3 describes this action. 
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T9 
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3100 ms. T8 T8/R9,T9./R9,T7/R1 Task T9 exceeds 

sentry 

3150 ms. T8 T8/R9,T9/R9,T7/R1 Task T9 resumes 

execution 

3200 ms. T8 T8/R9,T9./R9,T7/R1 



6500 ms. T9 T9/R8,T7/R10 

6550 ms . 



9550 ms 

9600 ms 
9621 ms 

9650 ms 
9700 ms 
9750 ms 
9772 ms 

9781 ms 

9800 ms 
9850 ms, 
9894 ms, 

9900 ms, 
9981 ms, 



T7 - has an assigned priority of R1 
T8 - has an assigned priority of R9 
T9 - has an assigned priority of R8 

Figure C-3 Task Sentry Operation 
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C.5 SUMMARY OF SCHEDULER OPERATION 

The four modes of scheduler operation are summarized in figure C-4. 
The modes in which either time slicing or task sentry are described in 
the previous paragraphs. The scheduler mode in which both time slicing 
and task sentry are used, acts like the time-slicing-only mode for 
lists with more than one task, and like task sentry only for lists of 
just one task, providing that the task sentry value is greater than the 
time slice value. This is because the task sentry timer is reset each 
time a new task is allowed a time slice. In the simplest scheduler 
mode neither time slicing nor task sentry is used. In any case, the 
highest priority task in the system is always in execution. 

Most industrial applications use time slicing only or neither time 
slicing nor task sentry. If timesharing, scientific programming, or 
other general purpose data processing functions are performed on the 
same machine with a real-time control function, the time-slicing-only 
mode should be used. In this case, the general purpose data processing 
functions can be carried out on priority levels 1-3, and the control 
programs can occupy priority levels R1-R127. If each control task is 
assigned a different priority level, no time slicing of the real-time 
control tasks occurs. The general purpose DP functions are allowed to 
use any CPU time not required for the real time control function. If 
only real-time control is carried out by the CPU, neither time slicing 
mode nor task sentry mode should be used. In this case, all tasks are 
assigned a separate priority level. Execution is nearly the same as 
described above for R1 -R1 27 tasks but there is slightly less system 
overhead since the operating system no longer performs the time slicing 
function. In critical response environments, this mode may provide the 
extra fraction of a second response required. Because of the response 
characterisitics of the real-time priorities, communications software 
is frequently given a real time priority. 
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Task Sentry 



YES 



NO 



YES 



NO 



At end of time slice, task 
is put on the bottom of the 
list for its priority 
level. If a task executes 
more consecutive system 
time units than specified 
for the task sentry, then 
the task is placed at the 
bottom of the next lowest 
priority list in the active 
queue . 



If a task executes more 
consecutive system time 
units than specified for 
the task sentry, the 
task is placed at the 
bottom of the next lowest 
priority list in the active 
queue . 



At end of time slice task 
is put at the bottom of the 
list for its priority 
level. 



Highest priority task has 
CPU as long as it wants it 



Figure C-4 Summary of Scheduler Operation 



NOTE 
The highest priority task is ALWAYS being executed. 



C.6 SUPERVISOR CALLS AFFECTING SCHEDULER OPERATION 



Another feature that is useful 
environment is the Do Not Suspend 
SVC causes the task scheduler to be 
making the call. This is the 
functions. Suspension is inhibitie 
specified number of system time 
seconds) . The task can suspend itse 
Wait for I/O, or Unconditional Wait 
used in place of the LIMI instruct 



in the industrial application 
supervisor call. Execution of the 
inhibited from suspending the task 
only way to override the scheduler 
d either 200 milliseconds or a 
units (50 milliseconds, to 12.750 
If by executing an I/O, Time Delay, 
supervisor call. This should be 
ion. 
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The following supervisor calls also affect scheduler operation: 

* Execute Task — Causes the initiation of a task that has been 
installed on any program file. 

* Activate Suspended Task — Reactivates a task that has placed 
itself in a suspended state by using the Unconditional Wait 
supervisor call. 

* Scheduled Bid Task — Activates a task at a specified time. 

* Time Delay — Suspends the calling task for the specified 
number of full system time units. 

* Change Priority — Changes the priority of the calling task. 

* Unconditional Wait — Suspends the calling task indefinitely. 

* Activate Time Delay Task — Activates a specified task that is 
in time delay. 
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APPENDIX D 

DEVICE STATES AND LUNO ASSIGNMENT 

Devices supported by DX1 have three possible states: online, offline, 
and diagnostic. When a device is offline, no LUNO can be assigned to 
it. When a device is in the diagnostic state, EUTIL sub-opcode >94 
must be used when assigning a LUNO to that device. 
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APPENDIX E 
VDT CHARACTER INPUT SVCs 



E.1 INTRODUCTION 

Two supervisor calls (SVCs) are available to input a character from 
specified VDT keyboard. They are SVC >08 and SVC >18. 



a 



E.1.1 VDT CHARACTER INPUT SUPERVISOR CALL fCODE >08) . 

This supervisor call inputs a character from a specified station 
keyboard. The calling task is suspended until the character is 
transferred. The system places the character in the most significant 
byte of the task workspace register 0. 

The supervisor call block consists of three bytes, and need not be 
aligned on a word boundary. Byte contains the code, and the system 
returns a value in byte 1. Byte 2 contains the station number. When 
the system is unable to locate the station, it returns -1 in byte 1 . 
When the station has not been opened in the character mode, or when 
power is off at the station, the system returns >80 in byte 1 . 
Otherwise, the system returns zero in that byte. 

The VDT character input call block is formatted as follows: 

Hex. 

Byte 

* + * 

>00 j >08 j ERROR CODE J 
+ + + 

>02 J STATION NUMBER J 
* * 

The following is an example of coding for a supervisor call block for a 
character input from station keyboard supervisor call. The SVC says to 
input a character from station 2 and place the character in the most 
significant byte of workspace register 0. 

SCBC BYTE 8,0,2 



E.1.2 VDT CONDITIONAL CHARACTER INPUT SUPERVISOR CALL (CODE >18). 

This supervisor call inputs a character from a specified station 
keyboard. When a character is entered, the function sets the equal bit 
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(bit 2) of the status register to 1 and places the character in the 
most significant byte of workspace register 0. When a character has 
not been entered, the function sets the equal bit of the status 
register to 0, indicating a "not equal" status. In either case, the 
function returns control to the calling task immediately. 

The supervisor call block consists of three bytes, and need not be 
aligned on a word boundary. Byte contains the code, and the system 
returns a value in byte 1. Byte 2 contains the station number. Afhen 
the system is unable to locate the station, it returns -1 in byte 1 . 
When the station has not been opened in the character mode, or when 
power is off at the station, the system returns >80 in byte 1 . 
Otherwise, the system returns zero in that byte. 

The VDT conditional character input call block is formatted as follows: 

Hex. 

Byte 

* I --* 

>00 ! >18 ! ERROR CODE ! 
+ + + 

>02 j STATION NUMBER | 
* ._, * 

The following is an example of coding for a supervisor call block for a 
conditional character input from station keyboard supervisor call. The 
SVC says to input a character from station 5 and place it in the most 
significant byte of workspace register if a character has been 
entered at the keyboard. 

SCBT BYTE >1 8,0,5 
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Appendix F 
THE SYSTEM LEVEL DEBUGGER 



F.l GENERAL INFORMATION 

The System Level Debugger is used for breakpointing and listing 
the contents of memory locations and registers when debugging the 
DX10 system root only. The primary purpose for the System Level 
Debugger is to debug DSRs. The debugger allows the user to 
control a program's execution and examine intermediate results in 
order to determine exactly where problems are occur ing. 



F.2 HOW TO LINK THE DEBUGGER WITH THE DX10 SYSTEM IMAGE 

The debugger is an option included at the time the system is 
generated. When prompted for DEVICE during system generation the 
user responds as follows: 

DEVICE: DEBUG 

Then, continue with the system generation process. 

To delete the debugger from a system enter the following after 
the DEVICE or NEXT prompt: 

DEVICE: C DEBUG 



F.3 PREPARING THE DX10 SYSTEM DEBUGGER 

£ rior to using the System Level Debugger the debugger image must 
be modified to specify the target terminal (the default terminal 
specification is a 913 VDT to which global LUNO 1 is assigned). 
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F.3.1 SPECIFYING INTERACTIVE TERMINAL TYPE 

The value in location >0A6C within the System Level Debugger 
determines the type of interactive terminal to be used. Consult 
the system linkmap for the location of the System Level Debugger 
within the system image. The System Level Debugger is module 
DEBUG in the system task. The following values indicate the 
terminal type: 

- ASR/KSR 
2 - 913 VDT 
4 - 911 VDT 



NOTE 

The System Level Debugger assumes the CRU 
address for a 911 VDT is >100. The CRU 
address used for 913 VDTs is >0C0. The CRU 
address for ASR/KSR devices is >000. These 
CRU addresses may be modified to allow 
communication with other terminals. To do 
so, the user must change the locations 
immediately following the terminal type 
address (>0A6C) . 



F.4 ACTIVATING THE SYSTEM LEVEL DEBUGGER 

The System Level Debugger is activated through XOP 1,1 
breakpoints. The breakpoint may be hard coded in a module or the 
System Level Debugger may be activated by entering the breakpoint 
through the front panel. The following procedure will activate 
the debugger in this manner, if the system is in an idle state. 

1. Press HALT. 

2. Press PC under DISPLAY. 

3. Write down the address displayed. 

4. Press MA under ENTER. 

5. Press MDD. 

6. Write down the value displayed. 

7. Press CLR. 

8. Enter >2C41 in the display lights. 

9. Press MDE. 
10. Press RUN. 



The debugger activates. Use the debugger to set the 
Step 6 back into the location from Step 3. 



value from 
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F.5 LIST OF THE DEBUGGER COMMANDS 

When the debugger is activated, it requests commands by 
displaying the question mark (?) on the screen. The user may 
then enter one of the debugger commands listed in Table F-l, and 
press the RETURN key. The debugger commands are described in the 
paragraphs following Table F-l. Each debugging command is 
specified by entering a single character. All command parameters 
are hexadecimal numbers displayed without the hex (>) sign. A 
number is automatically terminated after four digits are entered. 
A number can also be terminated by a period. 

Table F-l List of Debugger Commands 

Command Description 

C Display condition code in status register 

G Execute program being debugged 

I Inspect a range of memory locations 

J Display all workspace registers 

L List all instruction breakpoints 

M Display /alter contents of a memory address 

N Display/alter contents of next memory address 

P Display/alter program counter 

Q Quit debugging session 

R Display/alter contents of a work space register 

S Set instruction breakpoint 

W Display/alter workspace pointer 

U Clear breakpoint 

X Execute single instruction 

Z Resume execution after breakpoint 

+ Hexadecimal sum 

Hexadecimal difference 

? Display menu of commands 
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F.5.1 C Command — Display Condition Code in Status Register 
The C command displays the contents of the status register 
(condition code) and allows the user to modify the contents. 

Syntax: 

? C 

C= xxxx yyyy 
Explanation: 

xxxx is the current contents of the status register and 
yyyy is the value entered as the new status register 
contents (optional entry) . 

Example : 
? C 
C=C00F C10F 

The example shown lists the status register contents, 
>C00F. The contents are changed to >C10F. This sets bit 7 
of the status register, placing the computer in the 
privileged mode. If no value is entered, the register 
contents remain unchanged. 

F.5.2 G Command — Execute Program Being Debugged 
The G command executes the program being debugged. It is used to 
start the program initially, and can be used to proceed from a 
breakpoint. It is identical in function to the Z command when 
used to restart the program. 

Syntax: 

? G 
Explanation: 

This command requires no parameters. 
Example : 

? G 

The example initiates execution of the user program. The G 
command is used to start the program or in some cases to 
restart the program after stopping to examine register 
contents. 
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F.5.3 I Command — Inspect a Range of Memory Locations 

This command allows the user to inspect a range of memory 

locations in the local task address space. 

Syntax: 

? I 1111 uuuu 

xxxx xxxx . . . xxxx yy yy . 

Explanation: 



jtjt 



1111 is the lower address of the memory locations to be 
displayed (this is a required entry) . uuuu = is the upper 
address of the memory locations to be displayed (optional 
entry) . If uuuu is not entered, the debugger displays 
locations 1111 through 1111 + >F. If neither the lower 
address nor the upper address is entered, a message that an 
illegal hex value has been entered is displayed. Each xxxx 
is the displayed hexadecimal contents of a memory location. 
Each yy is the ASCII representation of the memory contents. 
The command displays >10 bytes per line, and fills the line 
of the display on which uuuu is displayed (that is a 
multiple of >10 bytes is always displayed) . 

Example : 

? I C000 C020 

2202 0006 0800 ... 5336 " S6 

0045 3132 3658 ... 0000 .E 12 6X 

3148 4444 2634 ... 5541 1H DD &4 ... UA 

The example displays the memory locations from >C000 to 
>C020. Memory location >C000 contains >220 2, location 
>C002 contains >0006, etc. Location >C020 contains >3148. 
The memory locations up to and including location >C02F are 
displayed, filling out the third line of the example. 
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F.5.4 J Command — Show All Local Workspace Registers 

This command displays all local workspace registers on one line 

of the display. 

Syntax: 

? J 

xxxx xxxx xxxx . . . xxxx 

Explanation: 

The J command requires no parameters. Each xxxx is the 
value in one of the workspace registers, through 15. 

Example : 

? J 

0002 4AC7 0000 0000 ... 0000 

The example lists the contents of all the workspace 
registers. Workspace register contains >0002, workspace 
register 1 contains >4AC7, etc. The listing displays all 
16 workspace registers. 

F.5.5 L Command — List All Breakpoints 

This command lists the absolute addresses of all breakpoints 

currently set in the program. 

Syntax: 

? L 

LOCATION 

xxxx 

xxxx 

Explanation: 

This command requires no parameters. Each xxxx is the 
displayed location of a breakpoint. 
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Example : 
? L 



LOCATION 

B610 

BC24 

j.ne example Snows the two breakpoints that have been set in 
the program, at locations >B610 and >BC24. 



F.5.6 M Command — Display /Alter Contents of Memory Address 
The M command displays and allows the user to alter the contents 
of a specified memory location. Only addresses currently mapped 
in the task space may be modified with this command. 

Syntax : 

? M nnnn 

M nnnn=xxxx yyyy 

Explanation: 

nnnn is the word address of the memory location the user 
wishes to display (required entry) . When nnnn is an odd 
number, the memory word at nnnn-1 is displayed, xxxx is 
the displayed value of the memory location. yyyy is the 
new value the user wishes to place in the memory location 
(optional entry) . 



Example : 



? M B680 



M B680=AQ02 A003 



The example displays the contents of memory location >B680. 
The value in that location is >A002, and the contents are 
changed to >A003. 
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F.5.7 N Command — Display /Alter Contents of Next Memory 

Address 

The N command allows the user to display and alter the contents 
of the next memory address after the address examined previously. 
This command is used in connection with the R, M or N commands. 



Syntax: 



? N 



nnnn=xxxx yyyy 



Explanation: 



nnnn is the displayed address of the next location, xxxx 
is the displayed value of the next location, yyyy is the 
new value the user wishes to place in the memory location 
(optional entry) . 



Example : 

? R 4 
R4=0022 



? N 

B00E=0400 0800 

This example shows an R command and an N command. The R 
command displays workspace register 4. The N command 
displays the contents of the next memory address. In this 
example the next memory address is workspace register 5, at 
location >B00E. The value in the workspace register, 
>0400, is changed to >0800. 



F.5.8 P Command — Display/Alter Program Counter 

The P command displays the contents of the program counter 

user may alter the displayed contents if desired. 



The 



Syntax: 



? P 



PC=xxxx yyyy 



Explanation: 



xxxx is the displayed program counter value, yyyy is the 
value to replace the currently displayed value. This is an 
optional entry. 
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Example : 

? P 

POBA20 BA2C 

The example displays >BA20 as the program counter contents. 
The contents are changed to >BA2C. 

F.5.9 Q Command — Quit Debugging Session 

The Q command terminates the debugging program and the task that 

is being debugged. 

Syntax : 

? Q 
Explanation: 

This command requires no parameters from the user. 

Example: 
? Q 

END DEBUG 

The message indicates that the system is in an idle state. 
If the user wishes to exit from the debugger entirely, he 
or she should enter a G command. 



F.5.10 R Command — Display/Alter Workspace Register 

The R command displays the contents of a workspace register The 

user may alter the displayed contents if desired. 

Syntax: 

? R 

Rn=xxxx yyyy 
Explanation: 

n is the workspace register number, from to F (this is a 
required entry), xxxx is the displayed workspace register 
contents. yyyy is the value (this is an optional entry) 
that replaces the displayed contents. 
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Example : 

? R4 
R4=2A60 2A64 

The example displays the contents of workspace register 4. 
The value in workspace register 4 is >2A60. The value is 
changed to >2A64. 

F.5.11 S Command — Set Breakpoint 

The S command is used to set an instruction breakpoint at any 
address currently mapped in the task space. When the breakpoint 
is reached, the contents of the program counter, workspace 
pointer, status register, and all current workspace registers (0 
through 15) are displayed. 

Syntax: 

? S yyyy 

Explanation: 

yyyy is the address for the instruction breakpoint (this is 
a required entry) . 



Example: 



? S C006 

The example sets a breakpoint at memory location >C006. 
When the task is executed, it stops at location >C006 to 
allow the user to examine registers, memory, etc., and make 
changes if necessary. The following values are displayed 
at a breakpoint: 



PC=C006 WP=473E ST=0003 (PC) =2C40 
0000 23C0 1000 3348 4566 7290 0000 



2448 



The first line of the display shows the current contents of 
the program counter, the workspace pointer, the status 
register, and the word at the address in the program 
counter. The second line of the display shows the contents 
of the 16 workspace registers, through 15. 
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F.5.12 U Command — Clear a Breakpoint 

The U command clears (removes) one or more instruction 

breakpoints. 

Syntax: 

* u y/y* 

Explanation: 

yyyy is the location of the breakpoint that is to be 
removed (this is an optional entry) . 

If yyyy is not entered, then all breakpoints are removed. 

Example : 

? U C006 

The example deletes an instruction breakpoint set at 
location >C006. 



F.5.13 W Command — Display /Alter Workspace Pointer 

The W command displays the contents of the workspace pointer. 

You can alter the displayed contents if desired. 

Syntax: 

? W 

WP=xxxx yyyy 

Explanation: 

xxxx is the displayed workspace counter contents, yyyy is 
the value that serves as a replacement for the displayed 
value (optional entry) . 

Example 

? W 

WP=B010 B030 

The example displays the workspace pointer contents, >B010. 
The displayed contents are changed to >B030. 
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F.5.14 X Command — Execute a Single Instruction 
The X command allows the user to step through the program being 
debugged, one instruction at a time. The contents of all current 
workspace registers are displayed after executing each 
instruction. The X command executes the instruction at the 
address in the program counter. 

Syntax: 

? X 

POxxxx 

rrrr rrrr rrrr . . . rrrr 
Explanation: 

This command requires no parameters from the user, xxxx is 
the displayed contents of the program counter. Each rrrr 
is the displayed contents of one of the workspace 
registers, through 15. 

Example: 

? X 

PC=B250 

0002 A020 0000 .. . 0000 

The example illustrates an X command to execute the 
instruction at the address in the program counter. The 
value in the program counter, >B250 , and the workspace 
registers are displayed. Workspace register contains 
>0002, register 1 contains >A020, etc. 



F.5.15 Z Command - — Resume Execution After Breakpoint 
When the Z command is entered, execution proceeds from the 
current breakpoint to the next breakpoint (if another breakpoint 
is present). The breakpoint is not cleared, and can be used 
again, unless a U command is issued. 

Syntax: 

? Z 
Explanation: 

This command requires no parameters from the user. 
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Example : 

? Z 

This example restarts program execution after it has 
stopped at a breakpoint. The Z command is used after a 
breakpoint is reached, and the user has examined and 
changed memory, register contents, etc., as desired. 

F.5.16 + Command — Add Hexadecimal Numbers 

The + command is used to display the hexadecimal sum of two 

hexadecimal numbers. 

Syntax: 

? + xxxx yyyy = zzzz 

Explanation: 

xxxx is a hexadecimal number (required entry) . yyyy is a 
hexadecimal number that is to be added to xxxx (yyyy is a 
required entry) . zzzz is the hexadecimal sum of xxxx + 

yyyy. 

Example : 

? + C420 2184 = E5A4 

The example adds >C420 to >2184 and displays the sum of 
>E5A4. 



F.5.17 - Command — Subtract Hexadecimal Numbers 

The (-) command displays the hexadecimal difference of two 

hexadecimal numbers. 

Syntax: 

? - xxxx yyyy = zzzz 

Explanation: 

xxxx is a hexadecimal number (required entry) . yyyy is the 
hexadecimal number from which xxxx is to be subtracted 
(required entry) . zzzz is the difference of the two 
numbers. 
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Example: 

? - 0048 21CE = 2186 

The example subtracts >48 from >21CE and displays the 
difference, >2186. 

F.5.18 ? Command — Display A Menu of Commands 
The ? command is used to display a menu of all available debug 
commands, showing the format of the commands and a brief 
description of each. 

Syntax: 

? ? 
Explanation: 

This command requires no parameters from the user. 
Example : 

? ? 

P - PROGRAM COUNTER 

W - WORKSPACE POINTER 

C - STATUS REGISTER 

R - MODIFY WORKSPACE REGISTER 

M - MODIFY MEMORY WORD 

I - INSPECT MEMORY 

J - DUMP ALL REGISTERS 

S - SET BREAKPOINT 

U - REMOVE BREAKPOINTS 

L - LIST ALL BREAKPOINTS 

X - SINGLE STEP PROGRAM 

Z - CONTINUE EXECUTION AFTER BREAKPOINT 

N - DISPLAY NEXT WORD 

+ - ADD 

SUBTRACT 

Q - QUIT DEBUGGER ? 

The user may select any of the commands or exit from the 
debugger by entering Q, waiting for the END DEBUG response, 
then entering a G command. 
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